Hi Everyone and the EM HAVE SC list,
This email serves as notice that the Comment Resolution Log for EDXL-HAVE-v2.0-WD04 has been uploaded with the following Description: "This is the Comment Resolution Log that corresponds to the EM TC discussion/vote to advance EDXL-HAVE-v2.0-WD04 to Committee Specification Draft and Committee Specification Public Review Draft status as of 08-14-2018." The url for this document is https://www.oasis-open.org/apps/org/workgroup/emergency-have/download.php/63705/EDXL-HAVE-V2.0-WD03-Comment%20Resolution%20Log.docx
Thanks for your consideration.
Respectfully Submitted,
Rex Brooks
Hi all,
At this point, as far as I can tell, it looks like we need for the EMTC to review and then pass a motion approving the publication of a specific document (presumably the one Scott sent yesterday), and then submit the publication request form [1] to get things started. It looks like this will be the third Public Review - CSPRD03.
I looked at the minutes [2] from the EMTC meeting yesterday, and they seem to confirm this understanding:EDXL Hospital Availability Exchange (HAVE) SC. Awaiting OASIS agreement on finalizing ``Notices'' section then we can then begin final review internally before an expected 15-day public review.Is this correct?
Also, I've looked over the document sent by Scott. I didn't see any publication-related concerns, except for a question about whether or not the TC intends to include line numbers.ÂThey are not included in Scott's document. There were line numbers in CSPRD02, but not CSPRD01. This is completely up to the TC; OASIS has no policy on using line numbers.
[1]Âhttps://www.oasis-open.org/resources/tc-admin- requests/15-day-committee- specification-draft-public- review-request
Best regards,Paul
On Wed, Aug 8, 2018 at 6:42 AM, Elysa Jones <elysajones@yahoo.com> wrote:
Sometimes the background is helpful for historical understanding. Many thanks Jamie for your timely response to Scottâs email. You have well responded to the specifics for our immediate need. Elysa
Sent from Yahoo Mail for iPhoneÂÂÂ Thanks for the background, Elysa.Â
ÂÂÂ On the HAVE document, I am responding in detail to Scott's separate note, which attaches the draft.Â
ÂÂÂ On TEP, which you also raised, I'll come back to this thread and reply further here, after getting HAVE out the door.ÂÂÂ I also included Paul Knight in these threads, because Chet Ensign is out this week, so any TC Admin functions in the short term can be addressed by Paul.
 Cordially Jamie
James Bryce Clark, General Counsel
OASIS: Advancing open standards for the information society
https://www.oasis-open.org/staff
EU Commission 2018 Rolling Plan for Open ICT Standards: http://j.mp/EUstds2018
Next OASIS/World Bank Borderless Cybersecurity conference, October 2018: https://us18.borderlesscyber.org/en/
On Mon, Aug 6, 2018 at 4:22 AM, <elysajones@yahoo.com> wrote:
Dear Jamie,
Â
Thank you for your detailed response. We have been working for many years through our Statement of Understanding (SOU) to publish joint work with OASIS and HL7 in the specific areas where emergency response touch the health domain. They take different forms depending on the need. To recap, there are three EMTC EDXL efforts where we began collaborating between the organizations: Tracking Emergency Patients (TEP), Hospital Availability (HAVE) and the Distribution Element (DE).
Â
Regarding TEP, there are data items in EDXL/TEP that are patient data used within the HL7 Admit/Discharge/Transfer (and RA) messages. Our path with this collaboration was to work with the Public Health Working Group to develop a bi-directional transformation specification to detail the mapping between the TEP data and the A/D/T (and RA) data. This transformation spec was developed as a Committee Note in OASIS terminology and as an Implementation Guide in the HL7 vernacular. This document was jointly released in September 2016. It is attached for your review. The SDOs agreed the publication matter as shown in the notes section to include a joint copyright. As HL7 now releases their specifications for free, the only concession we made was to release to the general public after a âmembers onlyâ period for the first 30-days. We continue to monitor any changes on either side to insure the document stays up to date.Â
Â
Regarding HAVE: Collaboration on this specification has been more difficult as there is not a mapping to be done with an HL7 message as with TEP. However, HL7 maintains the needed hospital facility information. This information is needed for routing emergency patients via EMS to hospitals that have the bed and facility capacity to handle the incoming victims. This does not include patient data. There is no specification like HAVE in the HL7 space. It took many meetings over several years with the HL7 CEO, Chuck Jaffee, former and current CTOs John Quinn and Wayne Kubic, Technical Steering Committee Chair Austin Kreisler, HL7 staff attorney Karen Van Hentenryck and the excellent guidance of John Roberts from the TN Department of Health to formulate a path forward. HL7 has a policy not to âendorseâ other SDO standards. They agreed HAVE was a valuable piece of work. There is data maintained by the Patient Administration Working Group that was pertinent â so what do we do? After some difficult, tedious, tight rope walking over several years we agreed to a join release. This was agreed by all parties above in addition to the Patient Administration working group with whom we have worked for the last couple of years to finalize the document. We have completed our work and now just need to finalize the notices section. Scott Robertson took the wording from notices section in the CN we jointly released for the TEP transform specification, modified it for our HAVE purposes and it has been reviewed by HL7 legal (see email from Karen dated June 7 where you were copied).
Â
Regarding DE: As you recall and were present over a decade ago we began this discussion noting the header used for the health information exchange would perhaps be able to work with our DE. That was before we had our SOU in place and we did not get any traction. HL7 (â7â because of the ISO layers) do not focus on transport, so we put this on a back burner in favor of getting TEP and HAVE through first. ÂWe developed our SOU and moved ahead with TEP and HAVE. Last year, we began working with the HL7 Security Working Group to flesh out the best way to exchange first responder data. There will be many hoops to jump through here as the HIEs, Sequoya, Trust Framework, ICAM, the NIST 800 guidance and others all come into play. As the US First Responder Network come on line (FirstNet) this will become more important. The EDXL/DE is written into the SAFECOM grant guidance. We are not sure yet where our collaboration with HL7 will land on this but Âwe are learning who the players are.
Â
I am delighted to have Beth integrally involved now with OASIS and like you say â a black belt in HL7. She is truly a remarkable resource. She knows well the players mentioned above and has watched us push this rock up a hill to this point. Scott has been a tremendous value to our EMTC work on all SCs. He attends meetings and contributes in all areas with his kind manner and solid technical knowledge.Â
Â
I hope this email clarifies your concerns. We hope to have this joint release published in Sept and have scheduled a Birds of a Feather (BoF) for Oct 2 during the HL7 Working Group meeting for socializing it with both HL7 and OASIS persons. In addition to providing us space and an opportunity to announce the BoF, HL7 has also given us permission to invite to that event non-HL7 registered guests. It will be an opportunity for OASIS member outreach as well. As the event is in Baltimore, it will enable us to invite DHS Office of Emergency Communications (OEC), Science and Technology (S&T) guests as well as FEMA and first responders in the area. Patient tracking is high on the list of DHS OEC initiatives. DHS S&T funded the early work in developing the draft specifications as well as experiments in the 2009-2011 time frame with patients originating in MD, transported to LA and TN tracked with TEP and placed in hospitals using HAVE for dispatch guidance. Already at HL7 will be interested persons from HHS, Defense Health Care, VA, Assistant Secretary for Preparedness and Response and many others that have an interest in this work.
Â
We are less than 60-days from the scheduled event and will need to accomplish a 15-day review prior with the joint notices section intact. Please let me know as soon as possible if there is more information you need or action on our part. I look forward to your response.Â
Â
Best regards,
Â
Elysa Jones, Chair OASIS
Emergency Management Technical Committee
Emergency Member Section Steering Committee
Â
Â
Â
Â
From: Jamie Clark <jamie.clark@oasis-open.org>
Sent: Friday, August 3, 2018 2:56 PM
To: Elysa Jones <elysajones@yahoo.com>; Rex Brooks <rexb@starbourne.com>; Scott M. Robertson <Scott.M.Robertson@kp.org>
Cc: Chet Ensign <chet.ensign@oasis-open.org>; Beth X. Pumo <Beth.Pumo@kp.org>; Jane Harnad <jane.harnad@oasis-open.org>
Subject: Draft CS HAVE 2.0 and coordinating with HL7 on joint workÂ
ÂÂÂ Dear EMTC folks: Â Thanks for your patience in working with us, as well as for all your great work on these specifications.
ÂÂÂ I think you have two possible challenges here -- particularly if this is going to be a CS --Â (1) creation of a joint document with two logos that's been signed off by BOTH sides; and (2) forking risks.
ÂÂÂ The current (2017) HL7-OASIS MoU does contemplate cooperation, and does in its Section 7.0 permit joint publication, but only so long as the rules of both orgs are each followed.
Â
ÂÂ ONE DOC WITH TWO ORGS
 Often when we do co-publication, both orgs create their own print of the same content -- looks very much like CAP published by OASIS versus CAP published by ITU. Same tech, two different corer pages and licenses.
 What your draft edit assumes is that there will be one unified doc, with both logos and licenses. That's OK with OASIS on the terms described in this message -- BUT requires explicit OK from HL7 too (obviously). So if you want to go down that path, how do we collect final HL7 templating and logo use OK from Chet's equivalent at HL7?
 As you can see from my attached markup of the front-matter pages, there are a bunch of places where that might need tweaking to accommodate both orgs' needs. Also, see the STIX v2 spec "Notices" section, for an example of two sets of IPR notices in serial: http://docs.oasis-open.org/ cti/stix/v2.0/cs01/part1-stix- core/stix-v2.0-cs01-part1- stix-core.html
Â
ÂÂ SUMMARY > you need HL7 signoff on any notices, statements or other content that allegedly speaks for HL7.
Â
ÂÂÂ FORKING
 Unfortunately the 2011 and 2017 MoUs between OASIS and HL7 expected only Committee Notes. If there is going to be an OASIS Committee Specification, or OS, with those kinds of licensing rights, you have a second issue, which is how to assure that HL7 and EMTC, each independently holding a right to the material, will not diverge and fork it in two directions later? Forking's not permitted by our rules (Liaison Policy submission rules).Â
Â
 It's possible to achieve this, but requires confirming that the two orgs both agree to do so. Thinking of this as an ongoing parallel process: in order to permit the two organizations to finally approve the same document, with all of its elements as edited, obviously one requirement is that each of the SDO groups has received not only its own input from its own members, but also all the other inputs from the "other" group that are incorporated in its final approved document.
 In order to stay in sync, obviously both organizations have to end up approving the same file document â and that's challenged by the fact that, as joint copyright owners, each unilaterally can change the whole thing. We're prohibited by OASIS policy from allowing a contribution that results in a CS or OS fork. To avoid that we have three options.
A. OASIS agrees to stop work after this version, and hand it over to HL7 for all future versions. No competition, no fork.  That's possible, although our liaison policy would require our board's approval, which they likely would give if that's what EMTC wants us to do.
B. The reverse: HL7 walks away and puts down their pen for good, so future versions are entirely in the hands of OASIS. Again, no further forking risk.
C. Both organizations agree to stay in sync together â which requires that they also agree (a) to continue to share all material it is submitted to either side with both sides, and (b) only to approve the final version of the other side has also improved file version. That would require a short memorandum of understanding, (covering an issues not in the current one) as that's how one SDO commits to stay in sync with another. Â This did not come up in the content of CNs that do not carry OASIS IPR Policy patent license rights;Â but if this will be a CS, it does.Â
Can and should such an agreement can be put in place? We have done so before, and an example is attached here. It resulted in jointly-branded OASIS-W3C publication of (several versions over time) of the WebCGM standard. Chet or I would be happy to discuss this with senior level of HL7 folks if you wish.
I also have included here, and want to commend to you the expertise and diplomatic savvy of, Scott's colleague Beth Pumo, who in addition to being on the OASIS board also is an HL7 black belt, and standards politics ninja first class. She might have some insider-HL7 help to offer as well.
It's my understanding when we started this process that the TC's intent, shared with Chet, on which the MoUs in 2011 and 2017 were based, were about sharing CN documents and notes, but not joint standards-track work. So, if we're understanding your intended outcomes now correctly, we need to add anti-forking terms as well.Â
ÂÂ SUMMARY > we need to add some stay-in-sync agreements to the MoU, if you are approving joint standards-track specs, or you are otherwise contributing back the work to HL7 so that theoretically they could choose to fork it.
Â
As a practical matter, good news here includes:
- It looks like you've been doing well so far, judging by the draft appendix C: you're passing the documents back-and-forth until it gets to a great final form. That's exactly the right approach, as long as there continues to be a promise by both sides to continue to share all future proposed changes, and not to create future separate versions without "leaving the other behind."
- You can publish YOUR version at any time, and then work out the right to use their logo, submit to them, and get their independent approval, later.
Â
Kind regards Jamie
Â
James Bryce Clark, General Counsel
OASIS: Advancing open standards for the information society
https://www.oasis-open.org/ staff
EU Commission 2018 Rolling Plan for Open ICT Standards: http://j.mp/EUstds2018Next OASIS/World Bank Borderless Cybersecurity conference, October 2018: https://us18.borderlesscyber. org/en/
Â
Â
On Thu, Aug 2, 2018 at 8:55 AM, <elysajones@yahoo.com> wrote:
Yes â VERY tights as we have to get in a 15-day review after getting Jamieâs input. Please expedite! Thanks, Elysa
Â
Â
Â
--
Paul KnightÂÂ-ÂTel: +1 781-883-1783
OASIS - Advancing open standards for the information society -ÂDocument Process Analyst
Borderless Cyber 2018,Â3-5 Oct, Washington, D.C.
Organized by The World Bank, OASIS, and Georgetown University
-- Rex Brooks Starbourne Communications Design Email: rexb@starbourne.com GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670