david mccallie, co-chair arien malec, co-chair march 26, 2015 health it standards committee...

David McCallie, co-chairArien Malec, co-chair

March 26, 2015

Health IT Standards CommitteeArchitecture, Services, and

API Workgroup

2

ASA Workgroup - Active Members

Name Organization

David McCallie, co-chair Cerner

Arien Malec, co-chair RelayHealth Clinical Solutions

Janet Campbell Epic

George Cole Allscripts

Josh Mandel Children's Hospital Boston

Gajen Sunthara, ex officio Department of Health and Human Services (HHS)

Debbie Bucci, staff lead HHS, Office of the National Coordinator

ASA WG Workplan

3

Meetings Task

February 10, 2015 – Joint Committee Meeting • Charged by HITSC with responding to the Interoperability Roadmap V.1

February 12, 2015 2:30 – 4:00pm ET • Comment on Interoperability Roadmap V.1

February 26, 2015 2015 2:00 – 3:30pm ET • Comment on Interoperability Roadmap V.1

March 12, 2015 2:30-4:00pm ET • Comment on Interoperability Roadmap V.1

March 18, 2015 – HITSC Meeting • Review current progress on Interoperability Roadmap V.1

March 26, 2015 2:00-3:30pm ET • Finalize comments on Interoperability Roadmap V.1

April 9, 2014 12:00 – 1:30pm ET • Overview of Certification NPRM and prepare to comment (anticipated date for planning purposes)

April 22, 2015 – HITSC meeting • Interoperability Roadmap V.1 comments to the HITSC

April 23, 2014 12:00 – 1:30pm ET • Comment on Certification NPRM (anticipated date for planning purposes)

May 7, 2014 12:00 – 1:30pm ET • Finalize comments on Certification NPRM (anticipated date for planning purposes)

May 20, 2015 – HITSC Meeting • Anticipated date to present Certification NPRM Comments to the HITSC

Composable API Era – Mapping to the hourglass

4

Data sharing Arrangements

Interoperability Use-cases

Orchestration Patterns

Core Composables

Internet Standards

Vendor implementations

Composable API Era – Mapping to the hourglass - Examples

5

The InternetHTTP + TLS

CoreComposables

CORE-Profiled-FHIROAuth2 OIDC

HTML5

Orchestration Patterns

Apps (SMART, mHealth) Peer-to-Peer Brokered-Trust

Pub-Sub

InteroperabilityUse-cases

Data SharingArrangements

SDC RFD Closed-Loop-Referrals InfoButton-2 Pop-Health Remote-CDSRx-as-App PDMP Prior-Authorization

Appropriateness-Screening

ACOs eHealthExchange CommonWellSureScripts Vendor-App-Stores

Referral-Networks

DRAFT General recommendations

• To create greatest modularity, move towards parsimony of– Transport and Security (HTTPS + OAuth2/OIDC)– Content (Profiled FHIR)– Common Orchestrations

• Adopt a deliberate policy of “rebalancing” the standards portfolio towards parsimony

• Allow sufficient time to develop, adopt and use to allow for success during the rebalancing period

• (Avoid use of “SOA” and “REST”– too generic and confusing)

6

DRAFT: Roadmap Recommendations: 2015-2017 (1)

• Create a glide-path to Core Composables and Orchestration Patterns by:– Supporting SDO and public-private (e.g., Argonaut, DAF)

work to define core composable API services and profiles (“Core”)

– Support SDO and public-private work to define orchestrations and related security components for SMART/mHealth Apps

– Support future work to define other key high value orchestrations and security components (e.g., Peer to Peer record access, Remote CDS, Pub Sub)

– Support priority use-cases work (e.g., CDS, PDMP, SDC, etc.) to be implemented in terms of Core + Orchestration Patterns

7

DRAFT Roadmap Recommendations: 2015-2017 (2)

• Reduce “friction” and distraction to adopters and implementers by– Minimizing certification requirements overall to allow ample

time to pilot, adopt and refine Core and Orchestrations– Ensuring that government incentives can be met using the newer

approaches, even if not formally adopted into Certified HIT.– Continuing to support production adopted standards not based

on Core (e.g. C-CDA, XCA/XCPD, etc.) while minimizing changes and new uses

– Avoiding endorsing new standards that are not based on Core, and seek alternatives that are based on Core (e.g., HPD+, CSD, HIEM)

8

DRAFT: Roadmap Recommendations: 2018-2024

• 2018-2020– Refine and extend core composable services, profiles, and orchestration

patterns– Expand the number of piloted use-cases based on Core– Address needs for national-scale services such as MPI, RLS, Directories, etc.– As Data Sharing Networks emerge, address needs for network-bridging

services– Consider mature APIs, orchestrations, and use-cases as candidates for

addition to Certified HIT– Begin transition from non-Core/Orchestration standards and APIs

• 2021-2024– As above +– Address complex data profiles that require more robust data models (CIMI)

as may be needed for the Learning Healthcare System– Contemplate transition to new Core/Orchestrations

9

DRAFT Transition Paths (For Discussion Only)

10

2015-2017 2018-2021

Direct and Directed Exchange

• Continue interoperable trust and EHR workflow

• Pilot FHIR-based content packaging and edge APIs

• Adopt FHIR-based content packaging and edge APIs

• Pilot and adopt native FHIR-based Directed Exchange

XCA/XDS • Continue interoperable trust and EHR workflow

• Use MHDv2 in parallel with XDS/XCA document exchange

• Pilot use of FHIR for discrete data exchange along with MHDv2

• Prefer MHDv2 for new go-lives

• Adopt discrete data exchange

• Start phase over from XCA/XDS to Core

Examples paths from production adopted standards to approaches based on Core Composables and Common Orchestrations

HITSC - Architecture, Services & APIs

Workgroup Architecture, Services & APIsONC FACA WG Lead(s) Debbie BucciChair / Co-Chairs • David McCallie, Jr., Chair, Cerner Corporation

• Arien Malec, Co-Chair, RelayHealth Clinical Solutions

General Questions (as they apply to the assigned Roadmap section)

• Are the actions proposed in the draft interoperability Roadmap the right actions to improve interoperability nationwide in the near term while working toward a learning health system in the long term?

• What, if any, gaps need to be addressed? • Is the timing of specific actions appropriate? • Are the right actors/stakeholders associated with critical actions?

Roadmap Section K. Standard, secure servicesL. Consistent, secure transport technique(s)

Charge / Question(s) • Does the roadmap advance towards the architectural and architectural patterns identified by ASA?

• Do the standards selected in the standards advisory advance towards the same?

• What changes to the roadmap are suggested to better meet the roadmap’s goals?

11

Interoperability Roadmap Section KAPI’s

Questions for Workgroup Discussion

General Questions• Are the actions the right actions to improve interoperability

nationwide in the near term while working toward a learning health system in the long term?


Workgroup Charge / Questions• Does the roadmap advance towards the architectural and

architectural patterns identified by ASA?• Do the standards selected in the standards advisory advance

towards the same?• What changes to the roadmap are suggested to better meet

the roadmap’s goals?

Category

2015-2017Send, receive, find and use a common clinical data

set

2018-2020Expand interoperable

health IT and users

2021-2024Achieve

nationwide LHSK1. API’s

Workgroup Member(s):

1. Through the coordinated governance process, health IT developers, SDOs, ONC and others should implement a coordinated approach to developing and standardizing a targeted set of public APIs for nationwide interoperability

2. HIT developers & SDOs should develop public APIs for (i.e., sending, receiving and finding a common clinical data set)

3. Certification bodies (including ONC) should develop certification approaches to encourage the adoption of specific or consistently functioning APIs as to reduce switching costs but that does not prevent the adoption of innovative new APIs

4. SDOs should advance and accelerate the development of standardized RESTful APIs

5. Health IT developers should work with SDOs to develop standards for interoperable electronic health devices

6. Stakeholder input requested 7. Stakeholder input requested

13

Charge Questions Comments

• Does the roadmap advance towards the architectural and architectural patterns identified by ASA?

(J. Campbell) In some cases, but not entirely.

To advance toward the architecture and patterns identified by this workgroup, the government would be better served by coordinating governance and testing tools around the waist of the interop hourglass. Activities around the periphery should be minimal, light touch, and focused around new use cases or incentivizing adoption.

(G. Cole) Yes, somewhat with the coordinated approach towards a targeted set of standard APIs.

• Do the standards selected in the standards advisory advance towards the same?

(J. Campbell) Yes, actually.

(G. Cole) Not really, but since it is a 2014 survey it should not be expected to provide that content.

(G. Cole) The standards advisory is an annual catalog of what already exits. FHIR is mentioned but its full of things that may not stand the test of time and does not reflect the forward thinking of the IR. It’s our responsibility to call out the items in the list that are immature, not used, etc..

(David) As core standards are agreed upon and orchestration patterns emerge that the standards advisory should focus on what patterns exits/what’s available.

• What changes to the roadmap are suggested to better meet the roadmap’s goals?

(J. Campbell) The roadmap should not focus on the specifics of the “how” of interoperability (e.g., a prioritization of REST). The roadmap should focus on the activities necessary to produce a vibrant and multi-use-case ecosystem that can flourish on a foundation of uniformity. The job of naming standards should be the job of the standards advisory (SA) and if the SA isn’t looking forward enough or structured to meet that need then we should fix that problem rather than add standards to the IR.

(G. Cole) Include the concept that maintenance, and versioning of APIs is as paramount to long term interoperability. Change the focus from certification to testing and the development of testing tools.

Interoperability Roadmap Charge Questions

1. Are the actions the right actions to improve interoperability nationwide in the near term while working toward a learning health system in the long term? 2. What, if any, gaps need to be addressed? 3. Is the timing of specific actions appropriate? 4. Are the right actors/stakeholders associated with critical actions?

14

2015-2017Send, receive, find and use a common clinical data set

Comments (Section K, API’S)

1. Through the coordinated governance process, health IT developers, SDOs, ONC and others should implement a coordinated approach to developing and standardizing a targeted set of public APIs for nationwide interoperability

(J. Campbell) Many coordinated approaches to such APIs (interfaces / use cases / whatever) already exist. It would be preferable for ONC, if they feel that such avenues are inadequate, focus on modifying or augmenting existing activities, rather than creating even more bodies and processes.

As mentioned, such activities provide the most return on investment at the narrow waist of the interop hourglass.

(G. Cole) Include the concept that maintenance, and versioning of APIs is as paramount to long term interoperability.

Unclear where and how a governance process across such a disparate group would convene, or work over time.

2. HIT developers & SDOs should develop public APIs for (i.e., sending, receiving and finding a common clinical data set)

(J. Campbell) Many public APIs for sending, receiving, and finding a common clinical dataset already exist. It is preferable to identify deficiencies and augment as necessary, rather than developing a new approach, unless a new approach is truly warranted.

Indeed, HIT developers and SDOs are developing public APIs for (?? there seems to be a word missing here). Perhaps this item should say that work should continue.

(G. Cole) Probably needs to define precisely some set as the minimal set, e.g. i.e the 2015 Common Clinical Data set.

(Arien) This work already exits, should be supported and augmented and this example, should be but an example, because there are many and multiple examples underway.

(Josh) we need usable API’s that meet certain design sensibilities. Whether it is or isn't an API isn't the point.


15

2015-2017Send, receive, find and use a

common clinical data setComments (Section K, API’S)

3. Certification bodies (including ONC) should develop certification approaches to encourage the adoption of specific or consistently functioning APIs as to reduce switching costs but that does not prevent the adoption of innovative new APIs

(J. Campbell) It’s unclear what the “switching costs” refer to here. If this is about the “switching cost” of moving between EHRs, it’s possible that an “API” as commonly perceived (a real-time business action or CRUD function restrained to a single workflow or piece of data) would be inadequate and inefficient, given that you eventually want to get rid of the old EHR. A onetime “move everything” batch job might be preferable.

I appreciate that the ONC recognizes this is one use case of many, but it should at least be pointed out that mandatory certification tends to lock in and ossify approaches, deincentivizing efforts to come up with other approaches.

(G. Cole) Disagree with this statement on developing an approach thru certification……many feel that there is an enormous gap in testing tools and that the existing certification program is not meeting the stated goals. Reword this to focus and relate to I. Testing tools (pg 76) I don’t think certification encourages adoption. It encourages studying for the test.

(Arien) We could interpret this question as being concerned with API versioning and transitioning to a more modular based approach in which case we applaud and agree with it. Is certification or testing the appropriate approach.

(Arien) We interpret this question as a laudable move towards thinking about versioning and forward looking so we do not impede progress. We applaud the direction. We would focus on testing and testing tools to meet the same aim as certification.


16


common clinical data setComments (Section K, API’S)

4. SDOs should advance and accelerate the development of standardized RESTful APIs

(J. Campbell) It’s not appropriate to mention a technology stack here. That’s what the Interop Standards Guide is for.

(G. Cole) No comment

(Arien) Point back to the hourglass model and reframe towards a parsimonious architecture

5. Health IT developers should work with SDOs to develop standards for interoperable electronic health devices

(J. Campbell) Agreed. I would suggest “continue to work” and that electronic health device manufacturers might also benefit from being involved in this conversation.

(G. Cole) Why do we call out electronic health devices? Interoperability is fostered by standardized content over secure, standardized transports. It is easy to understand, given the technology movements towards mobility and connectivity, that we may see additional opportunity to collect and disseminate healthcare content via devices, but this does not seem to belong here in the APIs piece of the roadmap.


2018-2020Expand interoperable health

IT and usersComments (Section K, API’S)

6. Stakeholder input requested

(J. Campbell) No comment


2021-2024Achieve nationwide LHS

Comments (Section K, API’S)




Interoperability Roadmap Section L1Common Transport Standards

18









Category


set


health IT and users

2021-2024Achieve

nationwide LHSL1. CommonTransportStandards


1. ONC will identify, and health IT developers should adopt, a minimum set of common transport standards to enable priority learning health system functions.

2. SDOs should update standards and health IT developers should adopt standards as needed.




19


common clinical data setComments (Section L1, Common Transport Standards)

1. ONC will identify, and health IT developers should adopt, a minimum set of common transport standards to enable priority learning health system functions.

(J. Campbell) Hardly anything objectionable here, although I suggest that identifying and prioritizing learning health system functions should come before the identification of the standards.

(G. Cole) “Minimum” should be emphasized here – the current meaningful use standards did not address transport in certain public health cases, and the proliferation of approaches resulted in extra and unnecessary development and testing work for all parties.

General comment: the focus throughout the document has been: send, receive, find and use….however the workflow patterns almost always follow the write once read many paradigm, suggesting that more emphasis should be put on Find and Use. Yes, stepwise it is easier to think about Send and Receive as early, perhaps even easy steps to take, but it is Find and Use that are of paramount importance and they actually do not require that either send or receive has happened.


(J. Campbell) Always a sound plan.



20

2018-2020Expand interoperable health IT

and usersComments (Section L1, Common Transport Standards)




2021-2024Achieve nationwide LHS

Comments (Section L1, Common Transport Standards)




Interoperability Roadmap Section L2Send

21









Category


set


health IT and users

2021-2024Achieve

nationwide LHSL2. Send


1. Public health agencies should converge on the use of standardized web services to support data submission as well as data query from registries and other systems.

2. Providers (including hospitals, ambulatory providers, long-term care centers and behavioral health providers) should adopt and use DIRECT to reach critical mass.

3. Providers and health IT developers should provide individuals with the ability to easily and securely transport their health data to a destination of their choice.



22


common clinical data setComments (Section L2, Send)

1. Public health agencies should converge on the use of standardized web services to support data submission as well as data query from registries and other systems.

(J. Campbell) Again, specific technical approaches belong in the Standards Guide, not the roadmap. I appreciate and stress that a single mode of transport would be preferable, especially compared to the current approach.

(G. Cole) Are 1, 2, 3 in some priority order? Is this saying that the focus of getting data sent to public health registries is priority number one?If we really want to have a Send 3, 6, 10 year plan, then work on writing the general Send goal, and have the 3 (or more) specific groups of public health, providers, and healthIT developers be broken out as targeted measurable environments with specific measurements that may vary over the timeframe.

2. Providers (including hospitals, ambulatory providers, long-term care centers and behavioral health providers) should adopt and use DIRECT to reach critical mass.

(J. Campbell) This is one case in which I might abandon my “no standards in the roadmap” cause, because Direct was already mandated as a part of Stage 2. Regardless of whether it was the right technical choice, certified EHRs support it, so maybe it’s time to do the necessary lifting (a resource location service keyed by NPPES, for example) to support it.



23


common clinical data setComments (Section L2, Send)

3. Providers and health IT developers should provide individuals with the ability to easily and securely transport their health data to a destination of their choice.

(J. Campbell) In general this seems reasonable. Standardizing approaches to this use case / pattern would be useful, since it might incentivize those destinations to support such patterns, thereby making it a smaller technical effort to support a wider range of destinations.



health IT and users

Comments (Section L2, Send)

4. Stakeholder input requested (J. Campbell) No comment



24

2021-2024Achieve nationwide LHS Comments (Section L2, Send)



Interoperability Roadmap Section L3Receive and Find

25









Category


set


health IT and users

2021-2024Achieve

nationwide LHSL3. Receive and Find


1. Health IT developers, providers and researchers should increase use of national standards for query functionality

2. Health IT developers, providers and public health agencies should increase use of national standards for publish/subscribe functionality.

3. SDOs should pilot, assess and refine standards for RESTful web services.

4. Health IT developers should widely implement national standards for query.

5. Health IT developers should widely implement national standards for publish/subscribe.

6. Health IT developers should implement national standards for RESTful web services as they are available.



26


common clinical data setComments (Section L3, Receive and Find)

1. Health IT developers, providers and researchers should increase use of national standards for query functionality

(J. Campbell) As this was an option in Stage 2 and as many EHRs already support it, I think it’s appropriate to include it here, although unlike Direct, it wasn’t mandatory.


2. Health IT developers, providers and public health agencies should increase use of national standards for publish/subscribe functionality.

(J. Campbell) I have concerns about this item and especially its timing, given that pub/sub has not been a part of any certification work to date. To me, it better belongs in the library of “other” patterns that are all really goo ideas but not yet a part of certification and maybe should be approached differently.

(G. Cole) It looks like this is really about Find, even with the introduction of publish/subscribe (which I think can be viewed as just another mechanism by which to Find).


27



3. SDOs should pilot, assess and refine standards for RESTful web services.

(J. Campbell) Discussion and naming of specific technical approaches is better left to the Standards Guide.


4. Health IT developers should widely implement national standards for query.

(J. Campbell) What’s the difference between “increase use” (#1) and “widely implement”? Assuming they are different, then maybe we should do the same thing in “Send” (L2).



28



5. Health IT developers should widely implement national standards for publish/subscribe

(J. Campbell) See my comments for #4, for the appropriateness of this item, and #2, for the appropriateness of pub/sub.


6. Health IT developers should implement national standards for RESTful web services as they are available. • National standards for

publish/subscribe• National standards for

RESTful web services (when available)

(J. Campbell) Does this really say that Health IT developers should implement national standards for RESTful services, specifically national standards for RESTful services? That seems unnecessarily redundant. Or is it saying that pub-sub should be RESTful?

Regardless, I recommend removing this one.



29





2021-2024Achieve nationwide LHS Comments (Section L3, Receive and Find)



david mccallie, co-chair arien malec, co-chair march 26, 2015 health it standards committee...

Documents

hitsc slide

pm et comment

roadmap recommendations

hitsc meeting anticipated

api workgroup slide

core composable api

profiles core support

planning purposes