[Openid-specs-heart] HEART Agenda 2016-10-3

[Glen Marshall [SRS]]

Regardless of our various experiences and perceptions, the core of my urging is to get HEART integrated into Health IT interoperability testing.  HL7 FHIR Connectathon testing is my first choice.  IHE Connectathon testing, which incorporates a broader set of standards-based interoperability, would be my second choice.  What I do not want to see is a third testing forum, as it would unnecessarily stress those who prepare for and attend the other tests.

The path into HL7 starts with a business plan, then a project, to author an implementation guide for HEART, ballot it, and test it in the FHIR Connectathon.  The path into IHE is similar, although it’s too late for getting into the 2017 Connectathon.

The ONC S&I Data Access Framework (DAF) took both paths, with success in HL7 and no uptake in IHE.  Since DAF is one of the core elements of Argonaut, which also has embraced SMART, I see the path into HL7 is already blazed for HEART.  Let’s plan to follow it.  A deliberate plan to test HEART in the HL7 FHIR Connectathon in January is aggressive, but I think it should be tried.


Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com<http://www.securityrisksolutions.com/>

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Tuesday, October 4, 2016 21:55
To: John Moehrke <johnmoehrke at gmail.com>
Cc: Glen Marshall [SRS] <gfm at securityrs.com>; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART Agenda 2016-10-3

With all due respect to John, and having worked with IHE extensively in the past, IHE is the main reason we're in the interoperability and data blocking predicament we're in today. The E in IHE stands for Enterprise and the focus of IHE is not the individual patient or even the physician, it's the business. I have lots of experience with other standards groups, including DICOM, that have been enablers of innovation. I have no experience with HL7.
From a patient perspective, HEART is broader than healthcare enterprises alone. Our perspective includes financial, social, research, and environmental services well beyond the "integrated delivery network" providers and vendors that dominate IHE. Identity and authorization management are not enterprise issues. They are people issues and we must keep HEART independent of the Integrated Healthcare Enterprise and under a broad, and consumer-oriented standards organization.
Adrian

On Tue, Oct 4, 2016 at 10:47 AM, John Moehrke <johnmoehrke at gmail.com<mailto:johnmoehrke at gmail.com>> wrote:
For all the various reasons you site; Specifically that the specifications HEART is developing are applicable beyond HL7, including DICOM and other.  I would rather see this work happen in IHE. There is no need to create new standards, this is an effort of constraining and guiding the use of existing standards. IHE already fulfills this role. IHE has a very basic profile of OAuth 2.0; looking much like the HEART one. I would far prefer that profiling happen in IHE, than in HL7.

That said, I don't see any reason why the move needs to be urgently started. HL7, IHE, and DICOM are already pointing at HEART as the workgroup that is developing these guidance. This was done in recognition of the compiled expertise and focus of HEART.

The unknown right now is what Argonaut's plans for SMART are. SMART contains yet-another profile of OAuth.  I understood that Argonaut would soon be proposing that specification be brought to HL7 FHIR.

As one of the HL7 Security WG co-chairs; I want a solution, but I want it maintained in a place that can best create and maintain it. I really don't think HL7 is the right organization.

What is the benefit of moving away from HEART? I originally expected that the specifications that HEART created could be transferred to IHE (or HL7) for long-term maintenance. No a creation effort, but a maintenance effort.  But I was told that HEART is not intending on moving their specifications. I understood that HEART was going to exist forever.

I suspect the question is: How can we get HEART specifications tested and part of regular-testing under the organizationship of HL7 FHIR Connectathon (and IHE Connectathon)? If this is the question, then I think we have a different set of work. We don't need to move specifications, we need to create a bright-line from HL7 and IHE to HEART (today the line might not be as bright as it could be); and we then need to create test plans, test tools, test bench, and test procedures. These all can be re-used at IHE and HL7; so there is no need to specialize them.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067<tel:%2B1%20920-564-2067>
JohnMoehrke at gmail.com<mailto:JohnMoehrke at gmail.com>
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Mon, Oct 3, 2016 at 11:26 AM, Glen Marshall [SRS] <gfm at securityrs.com<mailto:gfm at securityrs.com>> wrote:
Debbi,

I strongly urge that the HEART group plan and execute an entry into HL7 so it can influence the ongoing FHIR security and privacy work.  We need a successful health IT beachhead. And we need to establish incremental objectives, not a singular idealized goal.  Gaining a testing thread in the HL7 FHIR Connectathon in January is a stretch benchmark objective.

There are some administrative hurdles in HL7, e.g., establishing an official project within the Security workgroup.  To do that we need to write and present a business proposal.  The HL7 Security workgroup can help us understand the tasks for it.

While HEART has uses in other standards-based health data communication, FHIR has the collective ear of many people.  A successful effort in HL7 will then help lead to X12N<http://www.x12.org/x12org/subcommittees/asc-x12-rosters.cfm?strSC=N> (insurance claims), DICOM<http://dicom.nema.org/> (medical imaging), NCPDP<http://www.ncpdp.org/> (pharmacy), CDISC<https://www.cdisc.org/about/mission> (clinical research), ISO/TC 215<http://www.iso.org/iso/iso_technical_committee?commid=54960> (general health IT, including security), PCORi<http://www.pcori.org/> (patient-centered outcomes), etc.

Your thoughts?

Glen

Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452<tel:%28610%29%20644-2452>
Mobile: (610) 613-3084<tel:%28610%29%20613-3084>
gfm at securityrs.com<mailto:gfm at securityrs.com>
www.SecurityRiskSolutions.com<http://www.securityrisksolutions.com/>

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net<mailto:openid-specs-heart-bounces at lists.openid.net>] On Behalf Of Debbie Bucci
Sent: Monday, October 3, 2016 06:56
To: openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>
Subject: [Openid-specs-heart] HEART Agenda 2016-10-3

When: Monday 1 PM PST/4 PM EST
Where: Gotomeeting – https://global.gotomeeting.com/join/785234357
US phone number: +1 (619) 550-0003<tel:%2B1%20%28619%29%20550-0003>. Access Code 785-234-357


Agenda :
•  Recap decisions and/or clarifications made three weeks ago
•  UMA semantic profile
AOB

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart


_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart



--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161005/21b08c5c/attachment.html>