onc policy committee jason task force report.docx

8/9/2019 ONC Policy Committee JASON Task Force Report.docx

1/21

JASON Report Task Force

Final Report

October 15, 2014


2/21

Contents

Introduction and Executive Summary .................................................................................... 3

Assessment and Recommendations ....................................................................................... 4

Assessment ................................................................................................................ . 4

Recommendations ......................................................................................................... 8

Appendix A: Technical Details .......................................................................................... 15

Appendix B: Listening Session Description ..........................................................................18

Appendix C: AS!" Tas# $orce %em&ership ..................................................... .............. ... 19

Appendix D: 'ossi&le Implementation 'ath(ay )or 'u&lic A'I .................................................20


3/21

Introd ction and !"ec ti#e S $$ar%The *+,- AS!" Report ./A Ro&ust 0ealth Data In)rastructure/1 is highly critical o) the status andtra2ectory o) healthcare interopera&ility3 and recommends a ma2or shi)t in the 4S health exchange

paradigm5 It concludes that %4 Stages , and * have not achieved meaning)ul interopera&ility 6in any practical sense7 )or clinical care3 research3 or patient access due to the lac# o) a comprehensivenation(ide architecture )or health in)ormation exchange5 It points to the lac# o) an architecturesupporting standardi8ed A'Is3 as (ell as E0R vendor technology and &usiness practices3 as structuralimpediments to achieving interopera&ility5

AS!" recommends that healthcare interopera&ility &e reoriented a(ay )rom /siloed legacy systems/to(ard a centrally orchestrated interopera&ility architecture &ased on open A'Is and advancedintermediary applications and services5 In particular3 the report recommends an urgent )ocus on creating a6uni)ying so)t(are architecture7 to 6migrate7 data )rom these legacy systems to a ne( centrallyorchestrated architecture to &etter serve clinical care3 research3 and patient uses5 This architecture (ould

&e &ased on the use o) 6pu&lic7 A'Is )or access to clinical documents and discrete data )rom E0Rs3coupled (ith ena&lement o) increased consumer control o) ho( data is used5

The AS!" Tas# $orce . T$1 strongly agrees (ith AS!"9s call )or an orchestrated interopera&ilityarchitecture &ased on open A'Is as the )oundational approach )or nation(ide health in)ormationexchange5 The T$ also agrees (ith AS!"9s o&servation that current interopera&ility approaches

&ased on complex3 health care uni;ue3 document oriented standards and &usiness )rame(or#s are)unctionally limited and need to &e supplemented and perhaps eventually replaced (ith more po(er)ul3A'I &ased models5 The T$ thus also agrees (ith AS!"9s recommendation that %4 Stage - &e used asa pivot point to &egin the transition to an A'I &ased interopera&ility paradigm5

Though the T$ does agree (ith the main thrust o) the AS!" Report3 (e do ta#e issue (ith several o) its)indings and recommendations5 $irst3 AS!" does not accurately characteri8e the very real progress thathas &een made in interopera&ility3 especially in the last * years5 Second3 AS!"9s description o) currentgeneration clinical and )inancial systems does not accurately portray the &road range o) )unctionality o)these systems3 or the innovation occurring on those plat)orms5 Third3 the report addresses so)t(areengineering and architecture aspects o) interopera&ility &ut explicitly does not examine policy3 legal3governance3 and &usiness &arriers to health in)ormation exchange5


4/21

are included in %4 Stage -3 (e are at an a(#(ard moment in standards development: !lder standardssuch as >DS?>CA are mature &ut inherently limited3 (hereas ne(er A'I &ased standards are not yetready )or large scale adoption5 =e &elieve it (ould &e detrimental to loc# the industry in to olderstandards3 and thus3 (e recommend that !"C mo&ili8e an accelerated standards development process toready an initial speci)ication o) $0IR )or certi)ication to support %4 Stage -5

=e do not anticipate that this speci)ication (ould preclude the use o) other existing standards to meet %4re;uirements5 The simple goal is to ma#e such a $0IR speci)ication availa&le to vendors and providersalong (ith other existing )unctional speci)ications so as to o))er a via&le opening to those (ho (ouldinvest in ne( standards3 (hile at the same time not penali8ing those (ho are already investing incapa&ilities &ased on existing standards5

I) %4 Stage - is to &e leveraged3 various accommodations have to &e made &y private and pu&lic actors5!n the private side3 standards development needs to &e more highly )ocused and accelerated than it has inthe past3 and the industry has to ta#e more accounta&ility )or resolving interopera&ility &arriers (ithoutgovernment intervention5 !n the pu&lic side3 %4 Stage - should &e )ocused on interopera&ility to signal

to the mar#et the importance o) the issue and to allo( vendors and healthcare providers to )ocus resourcesappropriately5

@iven the long term nature o) this transition3 (e (ould not expect nor recommend that currentinteropera&ility activities &e halted or delayed in anticipation o) an A'I &ased )rame(or#5 Even (ith itslimitations3 the current )rame(or# )or document &ased exchange o))ers opportunities to improve the;uality3 sa)ety3 e))iciency3 and a))orda&ility o) care and (ill live in parallel (ith the gro(th o) an A'I

&ased approach )or some time to come5 These recommendations are )ocused on providing a meaning)ulspar# to (hat (ill undou&tedly &e a long industry (ide transition5

Assess$ent and Reco$$endationsThe AS!" Tas# $orce . T$1 revie(ed the AS!" Report through eight tas# )orce calls and t(o pu&lichearings5 =e have divided our conclusions into an assessment o) the report3 and speci)icrecommendations to the !))ice o) the "ational Coordinator .!"C1 &ased on our assessment5

Assess$ent!ur assessment o) the AS!" Report is &ased on (or#group deli&erations and )act )inding through t(o

pu&lic hearings conducted on uly * and August 5 A list o) the participants in the hearings as (ell as adetailed list o) our )indings )rom the hearings is contained in the Appendix5

The T$ has principal )indings regarding the ason Report:

1& T'e JASON Report(s concl sions re)ardin) t'e state o* interoperabilit% do not ade+ atel%c'aracteri e t'e pro)ress t'at 'as been $ade in interoperabilit% in recent %ears& -o.e#er, .ea)ree .it' JASON/s * nda$ental proposition t'at t'e ind str% is not %et positioned to ac'ie#et'e le#el and dept' o* 'ealt' in*or$ation e"c'an)e needed to s pport patients and 'ealt'carepro#iders in t'e * t re&


5/21

a5 The AS!" Report )ound that 6meaning)ul interopera&ility7 is virtually non existent in the4S3 and concludes that there is 6no rational access7 &et(een organi8ations )or clinical care or research5

&5 Timing o) the AS!" Reporti5 !ne limitation o) the report is that considera&le time has elapsed since the report (as

underta#en5 AS!" )irst received its charge )rom A0R approximately * monthsago .)all *+,*13 conducted its investigation in early *+,-3 and pu&lished its report in "ovem&er *+,-5 !) particular signi)icance is that AS!" s evaluation (asconducted F months prior to the launching o) %eaning)ul 4se Stage * in the mar#et.!cto&er *+,- )or hospitals3 and anuary *+, )or am&ulatory physicians15 Thus3

AS!" &ased all o) its conclusions on the results to date o) %eaning)ul 4se Stage ,re;uirements3 (hich3 &y design o) the program3 )ocused primarily on E0R adoptionrather than interopera&ility5

c5 Recent changes in interopera&ility driversi5 Since the initiation o) the AS!" report3 there has &een a signi)icant change in the

interopera&ility climate in the 4S5 Demand )or interopera&ility has gro(n

dramatically in the last ,G months3 driven &y %4 Stage * interopera&ilityre;uirements as (ell as simultaneous gro(th in value &ased contracting andaccounta&le care organi8ations .AC!s15 These ne( &usiness models have spurred)ocused demand )or interopera&ility to drive population health management3 caremanagement3 and analytics to support clinical decision support3 ;uality measurement3and predictive ris#5

ii5 The supply side is responding to meet this demand (ith the incorporation o) Direct protocols in E0R systems to ena&le secure sending and receiving clinical in)ormation &et(een clinical settings3 as (ell as nascent &ut gro(ing adoption o) capa&ilities to;uery and retrieve in)ormation )rom other settings through a (ide variety o) net(or#ssuch as single vendor net(or#s3 vendor consortia3 6private7 provider driven

net(or#s3 and 6pu&lic7 provider and payer colla&orative net(or#s at the national3regional3 state3 and local levels5

iii5 In the years since the AS!" report (as )irst given its charge3 there has &eenmeasura&le positive change in the interopera&ility capa&ilities availa&le in themar#et3 and an even larger positive change in the tra2ectory o) interopera&ility

progress5 That said3 (hile directional progress has indeed accelerated3 (e agree (ithAS!" that the goals o) interopera&ility are still not close to &eing achieved5

'articularly in the realm o) data level access3 most data gathering is happeningthrough &espo#e inter)aces one E0R at a time or among multiple E0Rs sold &y thesame vendor and installed in a coordinated )ashion5

*5 'ile t'e JTF a)rees .it' t'e JASON call to catal% e *aster pro)ress in interoperabilit%, .edisa)ree .it' t'e JASON assertion t'at s c' pro)ress can be ac'ie#ed b% replacin) e"istin)core clinical and *inancial s%ste$s 5

a5 AS!" Report assessment o) current industryi5 A )undamental tenet o) the AS!" report is that current E0R and )inancial systems

need to &e replaced in order to meet the goals o) their proposed so)t(are architecture5


6/21

ii5 AS!" also characteri8es the current mar#et as not conducive to innovation andentrepreneurship due to the dominance o) 6stovepipe legacy systems73 concludingthat current mar#et is not open to entrepreneurs and ne( entrants and that currentE0R and )inancial system vendors are not innovating themselves

&5 Hie( o) E0R is too narro(

i5 T$ &elieves that this vie( o) current systems is too narro( E0Rs per)orm an everexpanding set o) )unctions &eyond &asic capture and storage o) clinical notes anddata3 such as C'!E3 CDS3 and (or#)lo( orchestration

ii5 %any o) the )unctions highlighted in the AS!" so)t(are architecture are per)ormed &y E0R systems today3 al&eit not universally or uni)ormly .e5g53 4I applications3Semantics and Language Translation3 Search and Index $unctionality3 pu&lishedA'Is1

c5 Hendors starting to deploy A'Isi5 %any vendors already support A'Is3 and have numerous third party 6apps7

integrated into (or#)lo(sii5 0o(ever3 T$ ac#no(ledges AS!" concern that current A'Is are vendor

proprietary (hich could reduce the mar#et opportunity )or entrepreneurial developersand perhaps lead to vendor loc# in

d5 Evolutionary progress over revolutionary changei5 =e &elieve that innovation and entrepreneurialism are &est promoted &y )ocusing on

interopera&ility goals and open architecture through standardi8ed A'Is3 rather than onthe internal so)t(are design o) core clinical and )inancial systems

ii5 Accelerating evolutionary progress rather than trying to engineer revolutionary &ottom up change in so)t(are design is the only )easi&le path )or(ard in such a)ragmented mar#et and dynamic technological and &usiness environment

e5 AS!" Report vie( o) A'Isi5 The term A'I is a very &road term that generally descri&es so)t(are that allo(s

di))erent application programs to interact (ith each other )or speci)ic purposes5ii5 In the AS!" context3 6pu&lic A'Is7 are critical inter)aces that are standards &ased

(ith pu&lished speci)ications to ena&le extraction o) data and data representations)rom 6legacy7 E0R systems )or use &y other applications in the AS!" architecture5

iii5 =hile the T$ does not agree (ith the star# distinction that AS!" dra(s &et(een6legacy7 and )uture systems3 (e do strongly agree (ith AS!" on the need )oruniversal availa&ility o) 'u&lic A'Is to automate access to clinical documents andclinical data elements (ithin appropriate legal and &usiness )rame(or#s

& JASON proposes an a))ressi#e ti$eline *or enactin) * nda$ental c'an)e in t'e c rrent

interoperabilit% paradi)$, 'o.e#er, t'eir ti$elines ass $e t'at t'is is solel% a so*t.areen)ineerin) proble$ and do not take into acco nt 'i)'l% co$ple" interdependencies .it' nontec'nical *actors, s c' as b siness, le)al, polic%, and c lt ral *actors, .'ic' are $orec'allen)in) barriers to rapid c'an)e&

a5 Technical &arriers3 though challenging3 are eclipsed &y the policy3 legal3 &usiness3 and sociotechnical &arriers to greater interopera&ility

&5 AS!" ac#no(ledges the importance o) these non technical )actors3 &ut explicitly leavesthem out o) the scope


7/21

c5


8/21

a5 "eed )or transitioni5 The current path to(ards interopera&ility is &ased on standards and approaches that

are )unctionally limited and uni;ue to health care5 0ealthcare industry needs totransition to exchange &ased on contemporary and scala&le architectural principlesvia development and use o) a more comprehensive set o) 'u&lic A'Is5

ii5 There is currently no industry or government led plan or e))ort )ocused on all o) thestandards3 governance3 and incentive activities need to achieve u&i;uitous adoptiono) standardi8ed 'u&lic A'Is

iii5 This transition (ill not &e easy &ecause there are currently many demands onhealthcare providers and vendors5 Shi)ting the industry (ill re;uire concentrateddevelopment (or# &y vendors3 )lexi&ility in government incentive programs3 andecosystem maturation across the industry5

&5 Importance o) %4 Stage - and associated certi)icationi5 !"C and C%S have or may get various levers )or incentivi8ing adoption o) 'u&lic

A'Is )or use in DS"s5ii5 Although %4 policy levers have diminished in impact3 %4 Stage - remains a strong

in)luence and %4 certi)ication is the only currently esta&lished program to in)luence(idespread adoption o) open A'I speci)ications5

iii5 Thus it is very important that 0ITEC0 incentive re;uirements sta#e out an initial position that &egins the industry (ide introduction o) a 'u&lic A'I5

c5 "eed to )ocus %4 &y sharply limiting &readth o) %4 re;uirements in return )or )ocusedre;uirements targeting interopera&ility

i5 Recent experience (ith %4 Stage * and *+, Edition Certi)ication sho(s that overly &road and complex re;uirements can tax vendor and healthcare provider capacity

ii& "arro(ing the )ocus o) %4 Stage - and associated certi)ication (ill &oth send astrong signal to the mar#et on the importance o) interopera&ility3 and allo( healthcare

providers and vendors to concentrate development resources on 'u&lic A'Iimplementation

d& Three complementary 0ITEC0 levers should &e orchestrated:i& !"C should add certi)ication o) the Core Services o) the 'u&lic A'I to the set o)

standards associated (ith CE0RT51& This should &e done in a manner that accommodates more rapid evolution o)

Core Data Services than has &een possi&le (ith previous certi)icationapproaches5 Start (ith certi)ication o) simple services and then expandcerti)ications as mar#et experience matures5

ii& !"C and C%S should )ind (ays to encourage vendors to grant third party access to'u&lic A'Is &ased on agreed upon )air &usiness and legal conventions

iii& C%S should include in the re;uirements )or %4 Stage - incentives that healthcareorgani8ations allo( third party access to documents and data through the CE0RT9s'u&lic A'I according to agreed upon trust )rame(or#s and data sharing contracts5

1& %4 Stage - should encourage reciprocal exchange &y providing incentives)or sending or receiving

e& Timing is criticali5 AS!" recommended that !"C develop a plan )or an A'I &ased architecture (ithin

,* months3 ho(ever3 eleven months have already elapsed3 and the remaining %4Stage - timeline is shorter than ,* months5


9/21

ii5 !"C should immediately leverage the $ACAs to solicit and provide )eed&ac# )romthe mar#et and other government agencies to validate and )urther )lesh out theserecommendations

iii5 !"C should immediately contract (ith an SD! or other recogni8ed3 operationallyactive industry consortium to accelerate )ocused development o) initial 'u&lic A'I

and Core Data Service and 'ro)ile speci)ications )or inclusion in %4 Stage - andassociated certi)ication

iv5 Leveraging %4 Stage - (ill re;uire acceleration o) standards de)inition andtechnical development on the private side3 and ad2ustment o) the %4 Stage - rulema#ing process on the pu&lic side3 including the potential need )or delay orstaggering o) %4 Stage - incentives3 to account )or the time needed to standardi8eand then implement the Core Data Services o) the 'u&lic A'I5

2& T'e JTF reco$$ends t'at a $arket based e"c'an)e arc'itect re be de*ined to $eet t'enation(s c rrent and * t re interoperabilit% needs based on t'e *ollo.in) ke% concepts6

a5 Coordinated Architecture5 A loosely coupled architecture3 patterned on Internet principles3(ith su))icient top do(n coordination to ensure that a ro&ust and e))icient mar#et drivenecosystem o) interopera&ility (ill emerge5

&5 'u&lic A'I5 A standards &ased A'I that is to &e implemented (ith certain o&ligations andexpectations governing 6pu&lic7 access to the A'I5

c5 Data Sharing "et(or# .DS"1 & An interopera&le data sharing arrangement (hose participantshave esta&lished the legal and &usiness )rame(or#s necessary )or data sharing5 In thisdocument3 the data sharing net(or#s designated &y 6DS"7 are those that con)orm to thecoordinated architecture and use the pu&lic A'I5 This could include3 &ut is certainly notrestricted to3 existing net(or#s such as those run &y vendors or providers or healthin)ormation exchange organi8ations5 ."ote: !ur use o) the term /0IE/ is generic in natureand re)ers to general interopera&ility )unctions and should not &e con)used (ith healthin)ormation exchange organi8ations3 (hich are o)ten called /0IEs/ or /health in)ormationexchanges/51

d5 Core Data Services5 $undamental3 standards &ased data services that implementations o) the'u&lic A'I are expected to provide5

e5 Core Data 'ro)iles5 Data pro)iles that descri&e the content and )ormat o) the data exposed &ythe Core Data Services3 including de)initions and cardinality o) data attri&utes3 and value sets)or coded )ields5

& T'e nation.ide e"c'an)e net.ork s'o ld be based on a Coordinated Arc'itect re t'at 7loosel%co ples7 $arket based 8ata S'arin) Net.orks

a5 The Coordinated Architecturei5 =e do not recommend that the government attempt to create a single3 top do(n

architecture )or nation(ide interopera&ility5 =e recommend instead that nation(ideinteropera&ility &e )ounded on the principle o) loose coupling that has proven to &escala&le and )lexi&le to current and )uture implementation heterogeneity5


10/21

ii& A nation(ide approach to interopera&ility should tap into the dynamism o) themar#et to accomplish important societal healthcare o&2ectives (ithout sti)ling thea&ility o) mar#et players to continue to innovate to meet clinical and &usinessinteropera&ility needs5

iii& The Coordinated Architecture should &e modeled a)ter the principles that have

allo(ed the Internet to scale a core set o) tightly speci)ied services that ena&lemultiple heterogeneous ecosystems to emerge5

i#& =e do not envision the Coordinated Architecture &eing an entity or an actualin)rastructure implementation &ut rather a set o) standards and principles &ased oninternet style patterns and &uilding &loc#s .such as ReST)ul A'Is3 0TT'S3 !A4T03D"S3 etc15

b& Leverage and &uild upon existing net(or#s and exchangesi& There are already operating health exchange net(or#s in the mar#et today o)

di))ering levels o) maturity and )unctionality5 0o(ever3 they utili8e disparatearchitectures and standards )or exchange5 Any approach to a nation(ide architectureneeds to allo( )or certain net(or# speci)ic di))erences and &e responsive to )uture

mar#et needs )or interopera&ility5ii& =e expect that many existing net(or#s (ould ta#e advantage o) the 'u&lic A'I toenhance or replace existing capa&ilities5

c& The Role o) Data Sharing "et(or#s5i& 0IE net(or#s create &usiness and technical solutions that allo( independent entities

to interact (ith each other to per)orm speci)ic interopera&ility )unctions5 Thesenet(or#s must no( &e adapted to create &usiness and technical solutions that allo(such interopera&ility )unctions to &e per)ormed using a more comprehensive set o)services3 via the 'u&lic A'Is5

ii& "et(or#s that adopt 'u&lic A'Is )or health in)ormation exchange (ould &edesignated as Data Sharing "et(or#s .DS"s1 in the Coordinated Architecture5 There

are t(o #ey DS" roles that the Coordinated Architecture should address:1& Within the DSN 3 )acilitating exchange among entities &y leveraging the'u&lic A'Is5 This has a technical component .e5g53 (hat technologies areused to identi)y patients or authenticate users across entitiesJ13 and a policycomponent .e5g53 (hat data or documents are accessi&le through a 'u&licA'I3 and (hat are the allo(ed purposes )or data or documents accessedthrough a 'u&lic A'IJ1

2& Across DSNs 3 providing de)initions and standards )or services to &e used to &ridge across di))erent DS"s3 (hen this is deemed necessary5 This (ill havecross net(or# technical components .e5g53 (hich standards and protocols areused )or di))erent DS"s9 patient matching or authentication technologies to

interact (ith each otherJ13 and policy components .e5g53 ho( are /out o)net(or#/ entities authori8ed3 and (hat data or documents are accessi&le toauthori8ed /out o) net(or#/ entitiesJ1

iii& It is important to clari)y that clinical and )inancial systems that expose the 'u&lic A'I(ill have the a&ility to exchange data (ithout needing a DS"3 ho(ever3 the DS"s

provide important supporting policy3 legal3 and technical in)rastructure necessary )orroutine exchange3 much as trust arrangements among 0IS's support Directimplementations today5 A DS" does not necessarily have to &e an entity or an actual


11/21

in)rastructure implementation &ut could rather &e any arrangement that creates anecosystem to support 'u&lic A'I &ased exchange5

i#& DS"s (ould not &e limited to clinician to clinician exchange5 =e (ould expect thatDS"s (ill include those )ormed around existing net(or#s as (ell as novel andnascent net(or#s that )acilitate entities sharing a (ide array o) )ocused needs3 such as

research3 administrative transactions3 patient accessi&le transactions3 AC!s3 etc5

4& T'e 9 blic A I7 s'o ld enable data and doc $ent le#el access to clinical and *inancials%ste$s in accordance .it' Internet st%le interoperabilit% desi)n principles and patterns

a& Role o) the 'u&lic A'Ii& The 'u&lic A'I comprises t(o components

1& an implementation o) certain technical standards .the 6A'I712& an agreement to meet certain o&ligations governing /pu&lic/ access to the

A'Iii& =hat ma#es an A'I a 6'u&lic A'I7 is a set o) conventions de)ining 6pu&lic7 access to

the A'I1& A 6'u&lic A'I7 does not imply that data is exposed (ithout regard to privacy

and security52& An A'I provides the technical means )or access to E0R data3 ho(ever3 there

are legal and &usiness considerations that must &e addressed &e)ore any givenhealthcare provider and?or vendor (ould allo( another party to use the A'Ito access in)ormation5

& =hat is 6pu&lic7 in a 6pu&lic A'I7 is that the means )or inter)acing to it areuni)ormly availa&le3 it is &ased on non proprietary standards3 it is tested )orcon)ormance to such standards &y trusted third parties3 and there are (ellde)ined3 )airly applied3 &usiness and legal )rame(or#s )or using the A'I5

b& $0IR as the 'u&lic A'I Technical Standardi& Current exchange A'Is .such as >DS?>CA1 allo( access to structured and

unstructured documents3 &ut do not allo( direct access to individual data elements5There is currently no (idely accepted healthcare industry A'I that provides discretedata level access to E0R data5

ii& A healthcare 'u&lic A'I needs to ena&le access to &oth clinical documents .e5g53re)erral summary3 discharge summary3 etc51 and discrete data elements .e5g53medications3 la&s3 pro&lems3 etc51

iii& The T$ &elieves that 0LK $0IR .accompanied &y $0IR pro)iles1 is currently the &est candidate A'I approach to data level and document level access to healthcaredata5 .See the Technical Appendix )or details51

5& Core 8ata Ser#ices and ro*iles s'o ld de*ine t'e $ini$al data and doc $ent t%pes s pportedb% all blic A Is&

a5 Role o) Core Data Services


12/21

i5 The Coordinated Architecture and 'u&lic A'Is could ta#e years to completely spanthe )ull range o) healthcare data3 so the T$ recommends starting (ith more narro(data services )or an initial set o) high value use cases

ii5 The main )unction o) Core Data Services is to provide read and (rite access to themost important clinical data elements )ound in most clinical and )inancial 0IT

systems5 "ote that Core Data Services may also include necessaryauthori8ation?authentication speci)ications )or #ey use cases5 See the TechnicalAppendix )or more details5

iii5 Core Data Services might initially &e developed in the )ollo(ing )ive #ey areas3(hich are aligned (ith the target areas identi)ied in the AS!" Report:

,5 Clinician to clinician exchange .including ancillary service providers1*5 Consumer access-5 /'lugga&le/ apps )or consumers and )or clinicians

5 'opulation health and research5 Administrative transactions

&5 Role o) Core Data 'ro)ilesi5 The Core Data Services (ill &e made operational &y Core Data 'ro)iles3 (hich (ill

tightly speci)y the data elements .re;uired and optional1 used &y each o) the CoreData Services3 so that data )ormats3 codes and value sets can &e shared andunderstood &y &oth sending and receiving entities5

ii5 Rather than trying to &uild complex3 monolithic semantic translation?normali8ationservices such as suggested &y AS!"3 (hich are very di))icult to &uild at scale andare tightly coupled to speci)ic systems3 the T$ &elieves that it is much more )easi&le)or clinical data holders to implement local mappings to and )rom strictly de)inedCore Data 'ro)iles5

iii5 The initial Core Data 'ro)iles should )ocus on Clinician to Clinician exchange andConsumer Access (hich are high value and relatively )easi&le5

,5 Clinician to clinician exchange is a top priority to support care improvementand is the )oundation )or all other interopera&ility5 The 'u&lic A'I (illexpand on the document centric capa&ilities that exist in the mar#et today3 as(as recommended &y AS!"5

*5 Consumer access to discrete clinical data is a natural extension o) the currentdocument centric /Hie( Do(nload and Transmit/ and Blue Button patient

portal )unctions5 Consumer )acing 'u&lic A'Is can leverage already existing patient authentication and user management processes to ena&le a ne(ecosystem o) patient centered applications that use the 'u&lic A'I to accessthe patient s data5 There is a gro(ing and active community o)entrepreneurial developers in the m0ealth and /plugga&le app/ space (ho

are not constrained &y legacy so)t(are issues and (ho thus could &e aleading driver o) real (orld technical?ecosystem innovation and adoption5-5 =e expect that (idespread adoption o) the 'u&lic A'I (ill ena&le other use

cases3 (hich (ill li#ely proceed in the mar#et in parallel to the a&ove high priority items5 These uses could include improved semantically mapped data)lo(s )or population health and research3 as (ell as 6plugga&le apps7 )orclinician users5


13/21

:& ONC s'o ld asserti#el% $onitor t'e pro)ress o* e"c'an)e across 8ata S'arin) Net.orks andi$ple$ent care* ll% cra*ted, non re) lator% steps to catal% e t'e de#elop$ent o* 8SNs and t'eCoordinated Arc'itect re&

a5 "eed )or mar#et ecosystem to support 'u&lic A'Isi& Recent mar#et experience (ith Direct ma#es clear that implementing a technical

standard is not enoughii& Technical standards must &e em&edded in a mar#et ecosystem o) reasona&le and

customary practices in order to (or# seamlessly across all settingsb& Regulatory solutions are unli#ely to &e e))ective

i& !"C and C%S do not at present have clear regulatory authority over the activities o)data sharing net(or#s

ii& Developing and imposing strong regulatory authority (ould &e complex and di))icultto cali&rate given the large num&er o) disparate and heterogeneous emergingnet(or#s .e5g53 vendor driven3 transaction speci)ic 0IEs3 private 0IEs3 colla&orative0IEs3 etc1

c& Leveraging local governancei& Data Sharing "et(or#s (ill already have governance in place )or their o(n net(or#

activities3ii& Alignment o) these governance mechanisms to support loose coupling is a much

higher leverage and )easi&le approach than top do(n regulatory directivesiii& Attempts to supersede or displace existing DS" governance models could inter)ere

(ith the currently rapid gro(th in local3 regional3 and national exchange net(or#sd& Coordination &y a critical mass o) exchange net(or#s may soon &e achieva&le

i& %ar#et coordination has historically &een di))icult in healthcare due to the high)ragmentation o) healthcare providers and vendors

ii& 0o(ever3 current mar#et trends point to the possi&le emergence o) a critical mass o)

operational health exchange net(or#s (ith gro(ing national mar#et presence3 (hichcould ma#e mar#et &ased coordination more )easi&le than it has &een in the past

iii& Such mar#et &ased coordination has developed in many other industries (here acritical mass o) organi8ations )orm colla&orative governance and operating principles

e& $ederal government should ta#e the )ollo(ing #ey steps to help the industry overcomecompetitive and coordination &arriers

i& Transparency5 Aggressive and ongoing pu&lic monitoring o) the pace o) developmentand use o) net(or# mechanisms through collection o) A'I usage data anddevelopment o) an adoption evaluation )rame(or# to )acilitate 'u&lic A'I &asedexchange

ii& @uidance5 Issuing authoritative3 ongoing guidance to provide industry (ide direction

and &enchmar#s3 and to encourage speci)ic actions )or the development o) DS"s andthe Coordinated Architecture

iii& !rgani8ation5 Convening existing exchange net(or#s .i5e53 prospective DS"s1 tocataly8e adoption o) the 'u&lic A'I and development o) industry &ased governancemechanisms

*& $ederal government should ta#e the )ollo(ing steps to motivate adoption o) 'u&lic A'Is


14/21

i& Incentive alignment5 Aligning incentive programs and existing regulatory processesto stimulate use o) the 'u&lic A'Is3 such as AC! contracts3 LT'AC regulation3 la&regulation3 etc

ii& $ederal operational alignment5 Re;uiring )ederal healthcare entities to adopt the'u&lic A'Is in their technology procurement activities and day to day mar#et

interactions3 such as %edicare?%edicaid3 DoD3 Heterans Administration3 Indian0ealth Services3 "ASA3 etc5

g5 $ederal government may choose to ta#e the )ollo(ing steps to ena&le orchestration o) CoreServices across the DS"s

i& DS" &ridging standards5 Developing standards )or vendor neutral3 cross DS" &ridging to )ully ena&le the narro( set o) ro&ust transactions re;uired )or the looselycoupled architecture .such as patient identity reconciliation3authori8ation?authentication3 #ey management3 etc1

ii& "ation(ide shared services5 Developing standards )or3 and ensuring deployment o)3universally necessary shared services that are highly sought a)ter and thus (ould)acilitate DS" alignment3 such as pu&lic use licensed voca&ularies3 and perhaps

nation(ide healthcare provider and entity directories3 etc5'& The government may choose to consider direct regulation o) DS"s in the event that themar#et does not develop e))ective coordination mechanisms

i& As noted earlier3 such actions (ould involve a signi)icant increase in thegovernment9s regulatory authority over health in)ormation exchange activities3 (hich(ould have the ris# o) unintended conse;uences that could slo( mar#et progress

ii& Any such increase in regulatory authority should &e care)ully considered throughevaluation o) reasona&le and meaning)ul &enchmar#s and speci)ically cali&rated toaddress any remaining &arriers that the mar#et has )ailed to overcome


15/21

Appendi" A6 Tec'nical 8etails

Coordinated Arc'itect re

,5 The Coordinated Architecture should )ollo( these high level architectural patterns:a5 The architecture should &e &ased on loosely coupled systems that leverage the core

&uilding &loc#s that have allo(ed the Internet to scale5 These Internet &uilding &loc#smay include .&ut are not limited to1 I'3 0TT'S3 !Auth*3 and D"S

&5 The architecture (ill leverage the 'u&lic A'I .as de)ined &elo(1 and other services3 tocreate a loose coupling o) heterogeneous systems5

c5 The architecture should &e designed to support asynchronous upgrades &y allo(ing )or areasona&le degree o) 6version s#e(7 during rolling upgrades as standards evolve5 See

&elo( )or details5d5 Respect 'ostel s principle .send conservatively receive li&erally1

e5 Support use case appropriate3 standards &ased authentication and authori8ationtechnologies (hich should &e implemented using &est practice encryption and #eymanagement5

*5 The architecture should anticipate that multiple Data Sharing "et(or#s .DS"1 (ill use the 'u&licA'I5 These DS"s may address di))erent use cases3 or may re)lect di))erent &usiness drivers inheterogeneous settings5

a5 Typically3 a DS" (ill create the proper legal and &usiness )rame(or# in (hich actualinterchange is accomplished using the 'u&lic A'I5 DS"s may also chose to addressnet(or# speci)ic in)rastructure such as identity management3 #ey management3 consentand pre)erence trac#ing

&5 DS"s (ill also address the necessary legal agreements around data use and licensing

.e5g53 D4RSA3 etc51c5 I) the emergence o) multiple DS"s &ecomes a &arrier to interopera&ility3 then net(or#

&ridging agreements and services may &e needed3 and should &e addressed as part o) theCoordinating Architecture process5

-5 The various DS"s may ena&le the 'u&lic A'I to &e used )or patient care3 &ut should not &elimited to patient care5 The 'u&lic A'I should also &e used to address consumer access to theirhealth data3 cross provider population health aggregation3 as (ell as to ena&le the researchcommunity in service o) the learning healthcare system5

a5 Harious users o) the 'u&lic A'I should see# to reuse the Core 'ro)iles as much as possi&le3 &ut should allo( )or necessary pro)ile variations &y domain o) usage3 since dataneeds and access patterns may vary

,5 The 'u&lic A'I should also &e exposed in support o) 6apps73 6modules7 and other mechanismsthat encourage innovation around 6plugga&le7 extensions to &aseline clinical and )inancialsystems5

a5 The T$ &elieves that support )or 6plugga&le applications7 is a #ey aspect o)interopera&ility3 and should &e considered an important interopera&ility target o) theCoordinated Architecture and the 'u&lic A'I5

*5 The Coordinated Architecture should start (ith simple goals and technical standards3 &ut shouldanticipate emerging higher )unctions .e5g53 )ollo( the 6Internet 0ourglass7 pattern (herein a


16/21

small num&er o) homogenous core standards can &e expanded to address many heterogeneoususes51

-5 $uture cross DS" orchestrated services may &e needed5 Initially3 cross organi8ationinteropera&ility is &est addressed &y the emerging Data Sharing "et(or#s3 though over time itmay ma#e sense to create cross DS" connections via net(or# to net(or# &ridges5 Cross DS"

services could include:a5 Identity management .healthcare providers and patients3 and other endpoints1 &5 Authentication3 authori8ation3 #ey managementc5 Consent and privacy pre)erencesd5 Directories and data indexing services .)or example3 in supporting Internet li#e search

services1e5 Complex orchestration and transactions services .S!A1

blic A I 8e*inition

An implementation o) the 'u&lic A'I (ill have the )ollo(ing characteristics:,5 Shall support all o) the Core Data Services and Core Data 'ro)iles3 as long as the Data Service is

relevant )or the implementing module or service that exposes the 'u&lic A'Ia5 $or example3 a module implementing only eRx (ould not need to expose services that

are not part o) electronic prescri&ing )unctions5*5 Shall support pu&lic documentation )or the exposed Core Data Services and associated Core Data

'ro)ilesa5 %ay support exposure o) Custom Data Services and?or Custom Data 'ro)iles as

extensions o) the core data services5i5 I) custom data services are exposed that go &eyond the Core Data Services3 the

implementation shall )ollo( the underlying standard s regular method )orexposing extension services and extension pro)iles3 (here possi&le5

ii5 Extended services should not duplicate services that are already de)ined in theunderlying data service standard5 4se the standard &ased services (here

possi&le5iii5 Custom extensions should support pu&lic documentation o) the custom services

and custom pro)iles-5 In addition to supporting the Core Data Services and 'ro)iles3 an implementation o) the 'u&lic

A'I:a5 Shall ena&le access to and use o) the Core Services in a (ay consistent (ith the 'u&lic

A'I !perating Rules and @uidelines as de)ined a&ove5 &5 Should &e validated against rigorous certi)ication tests

c5 The Core Data Services and Core Data 'ro)ile certi)ication tests should &e closelycoordinated (ith the entities that are responsi&le )or the Core de)initions5 This is toensure that there is no mismatch &et(een the standards and the certi)ication tests o) thestandards5

d5 Should &e accompanied &y a implementer provided 6sand&ox7 that ena&les testing &yexternal entities .(ith proper access1


17/21

Core 8ata Ser#ices

,5 Core Data Services (ill include &oth read and (rite access to data3 as speci)ied &y thecorresponding Core Data 'ro)iles5

*5 The T$ considers $0IR and $0IR 'ro)iles to &e an emerging exemplar o) this pattern3 andrecommends strong consideration o) $0IR as the &asis )or the Core Data Services and Core Data'ro)iles

-5 The T$ &elieves that the approach o) using 'ro)iles to de)ine on the (ire 6semantics &ycontract7 ma#es &est sense )or rapid development o) the Coordinated Architecture5 Byconstraining the Core Service data elements to match speci)ic 'ro)iles3 the degree o) semanticmismatch can &e dramatically reduced5 Core Data 'ro)iles (ill de)ine the optional and re;uireddata elements and the codi)ication o) those elements )or speci)ic use cases5 These pro)iles are #eyto a loosely coupled architecture5

5 Core Data Services (ill include access to &oth clinical documents .e5g53 CCDA3 dischargesummary3 etc51 and discrete clinical data elements .e5g53 pro&lems3 medications3 allergies3 etc51

a5 It may &e necessary to de)ine a )e( core data services that are not strictly )ocused on dataaccess5 $or example3 healthcare speci)ic pro)iles )or !Auth* could &e considered )orCore5

5 Expanded Core Data Services should &e care)ully versioned such that implementations canidenti)y (hich version o) the Core Services is supported

a5 Hersioning should support reasona&le levels o) )or(ard and &ac#(ard compati&ility inorder to allo( )or rolling upgrades across the Data Sharing "et(or#s

&5 =hen standards are updated3 the overall net(or# must permit &ilateral interoperation &et(een a node that has updated to the ne( )eature or re;uirement and one that has not

c5 "odes that have installed the update must continue to receive and process actions usingthe old version3 although they may not &e a&le to per)orm ne( )unctions ena&led &y theupdate

d5 Standards should speci)y a method (here&y nodes on the old version can accepttransactions )rom a node on the ne( version and provide all the )unctionalitycontemplated in the old version5

e5 Bilateral inter version compati&ility should &e maintained )or a period o) time speci)iedin governance5


18/21

Appendi" ;6

,5 Exchange Service 'rovidersa5 David 0orroc#s3 Chesapea#e Regional In)ormation System )or our 'atients .CRIS'1

&5 Ted Mremer3 Rochester R0I!c5 itin Asnaani3 Common=ell 0ealth Allianced5 Eric 0e)lin3 0ealthe(ay

*5 Researcha5 =illiam Tierney3 Regenstrie) Institute

&5 Sarah @reene3 'atient Centered !utcomes Research Institute .'C!RI1c5 Landen Bain3 CDISC

d5 @(en Darien3 Cancer Support Community-5 Standardsa5 @rahame @rieve3 $ast 0ealthcare Interopera&ility Resources .$0IR1

&5 Thomas Beal3 openE0R c5 Steve Emric#3 "ational Li&rary o) %edicine ."L%1d5 Stan 0u))3 0ealthcare Services 'lat)orm Consortium

8a% 2 =5 A ) 2014>

5 Consumer )acing ecosystemsa5 Ali Emami3 0ealthHault

&5 ohn %attison3 Maiser c5 Mevin Riddle&erger and 'atric# Leonard3 iTriaged5 @ordon Raup 3 Datuite5 Anil Sethi3 @liimpse

5 Hendor A'Isa5 Charles 'arisot3 E0RA

&5 @eorge Cole3 Allscriptsc5 Carl Dvora#3 E'ICd5 Ryan 0amilton3 Cerner

F5 App 'rovidersa5 Dave Hoc#ell3 Ly)echannel

&5 Tim %ichals#i3 'oint o) Care Decision Supportc5 "ate =einer3 Avhanahealthd5 Chris Burro( and Steve %ic#elsen3 0umetrixe5 Denis Coleman3 App%edicine)5 onathan Baran3 health)inch

Appendi" C6 JASON Task Force 3e$bers'ip


19/21

3e$ber Na$e Or)ani ation Role

David %cCallie Cerner Co Chair

%ic#y Tripathi %A e0ealth Colla&orative Co Chair

Deven %c@ra( %anatt %em&er

@ayle 0arrell $lorida State Legislator %em&er

Larry =ol) Mindred 0ealthcare %em&er

Troy Seagondollar Maiser %em&er

Andy =iesenthal Deloitte %em&er

Arien %alec Relay0ealth %em&er

Meith $iglioli 'remier3 Inc5 %em&er

=es Rishel %em&er

Larry @ar&er Reliant %edical @roup %em&er

osh %andel Boston Children9s 0ospital %em&er

Landen Bain CDISC %em&er

"ancy 5 !rvis $0A?DoD Ex !))icio

Tracy %eyer $0A?!"C Ex !))icio

on =hite 00S Ex !))icio


20/21

Appendi" 86 ossible I$ple$entation at'.a% *or blic A I

The )ollo(ing diagram maps current standards and approaches to AS!" speci)ied gaps5

The )ollo(ing ta&le identi)ies current standards and services that (ould )orm the )oundational &uilding &loc#s )or a 'u&lic A'I

Cate)or% at'.a% or Approac'Base standard )or 'u&lic A'I and Core DataServices

$0IR

Document access Initially continue >CA?CCDA3 phase over to $0IR Authori8ation?Authentication E0R to E0R: "et(or# speci)ic .!A4T0J1

Consumer access via tethered portal: !Auth*?!IDC.i5e53 updated Blue Button 'ull3 S%ART on $0IR1

Semantics 4se $0IR 'ro)iles )or initial phase5 In later phasesexplore tying 'ro)iles to speci)ic Clinical %odels

"ational Halue Set repository ."L%1 )or core pro)ilevalue sets

%odularity S%ART on $0IR )or E0R and 'ortal 6apps7Complex transaction orchestration through S!Amodules

'opulation health data $0IR &undles3 $0IR pu&?su&


21/21

onc policy committee jason task force report.docx

Documents