|8:00 am–8:30 am
|8:30 am–9:15 am
|Introductions and Agenda Review
- Sponsor Communications
- Search for an ITI Board Representative!
- Agenda Review
- Patent Disclosure
- Decision Making and Goals
- Author commitments
- wiki updates, T-cons, F2F participation, ...
- continuos development: [Continuous Development]
Participants: Luke Duncan (Intrahealth) , Ben Levy (Corepoint), Spencer LaGesse (Epic), Amid Trivedi (himss), Vassil (Epic), Sylvie Colas (ASIP), John Moherke (ByLight), Elliot Silver (Change Healthcare), Lynn (ITI Tech PM), Joe Lamy (SSA), Umberto Cappellini (Grapevineworld), Mauro Zanardini (Arsenàl.IT), Gregorio Canal (Arsenàl.IT), Tarik Idris (ICW), Derek Ritz (ecGroup), Chris Melo (Philips)
Continuous development (John) See wiki Material
- John started putting down rules/issues: in accordance to the actual governance.
- The intent is to pilot the continous development this year, starting with a subset of those points, and create a prioritarization of actions in order to make this process usable in the future also by other domains.
- The primary goal is the ability to work on smaller and larger projects: wht the final goal to produce higher quality deliverable (profiles).
- One of the main issues will be how to do the planning evaluation. John is proposing to use t-cons (monthly decision call organized by the planning co-chairs) to get proposals in reviewable form ready for the next available f2f meeting. John and Sylvie will figure out how to maintain the list of propsals, and how to do the assesment during each F2F.
- Vassil would like to propose a less invasive change in our process: keep dedicated planning meetings twice a year, 2 entry points each year. Potentially iterating 1 year, but for small projects we could catch up with the previous cycle and complete in 6 months.
- Another important point is to not have public comments once a year from 3 domains at the same time. This put a lot of burden to cmte members in a 2 months period…
- The proposal will ask also to change the meeting organization. We would like to reduce the number of meeting to 4, full week meetings canceling the planning f2f.
|9:15 am–10:00 am
|Facilities and Hierarchies in FHIR
Minutes: Luke Duncan : Facilities and Hierarchies
- Elliot: raise the point that this seems to be a fundamental gap in the fhir modeling, shall we address it or hl7 should be in charge?
- Some additional points are that FHIR community seems interested in fixing this… There are a couple of discussions in Zulip related to this topic See this for example
- We can identify in this proposals two problems that would be addressed: multiple views for hierarchies and distinction between location/organization does not map well with the definition of facilities. First can be done using extension, not big deal (and IHE is a good venue in order to create and maintain this extension). The second is a more fundamental change. We could push this to FHIR core, saying that they have a problem… however this will affect only R5, that probably will come out in 2020...
- Luke goal is to described how to use the existing R4 resources to fulfill the need, and probably affect the changes in FHIR core in rder to fix it in R5.
- John sponsored this approach IHE is the good organization where to define extensions and where to analyze in detail the FHIR core Gaps.
|10:00 am–11:15 am
|Add RESTful capabilities to DSUB
Minutes: Mauro: DSUB notify
- After planning cmte review the propsal has been changed a little bit. This because there was a strong push form different vendors to cover other use-cases. So the goal is also to cover some Lacks open in DSUB profile: reliable notifications, search for pending subscriptions, update of subscriptions, and email notifications (on that field: every year we receive a request about different vendors about the deprecation of NAV… this profile could solve also those gaps).
- In accordance to proposal the minimal set of functionalities that we should profile in order to declare success is the full of a subscription resource. However the tech group does not agreeed on this because we can’t restrict to that for a whole profile, the base use-case shall include also the notification capabilities. It is clear that there are proprietary ways in order to do that (See Android FIREBASE, or iOS push notification mechanism) but we need to profile this.
- another important goal is to develop the profile so that the backend may be eventually DSUB: it shall be interoperable with the actual DSUB solution.
- The profile should work with the main document sharing platform already defined by IHE: XDS.b , MHD and NPFSm.
|11:15 am–11:30 am
|11:30 am–12:30 am
|Enhance ITI-44 and ITI-46 transactions (PIXv3 Feed and Update Notification) to support also patient delete/deactivation and unmerge Slides
Minutes: Tarik: Enhance PIXv3
- The goal of the proposal is only for Patient Deletion in order to fit GDPR requirements. The unmerge capabilities are out of scope (we identified that the unmerge functionality has too many implications in the Document Sharing world, and probably could not be addressed in a standardized way (there are local policies that need to be applied) ). HL7 v3 does not have deletion message, so we need to define it.
- The technical result will be: addition of a new message type in transaction [ITI-44] for patient deletion.
- But probably It has not only this implication, because we need to look into XAD-PID supplement in order to see if there are dependencies for [ITI-64] and maybe other transactions… (e.g. Delete Documents?). In fact, the outcome could be a trigger for further deletion of documents inside the Registry/Repository.
- This will be addresed as an option for [ITI-44]. And this option also describe how this transaction CAN trigger delete document transactions ()this should not be a Requirement, but we need more analysis on this topic ).
- Probably we will come out with: 2 Options one for the registry and one for the PIX source.
- BLOCKING ISSUE: we do not have an editor for this work-item.
|12:30 am–1:30 pm
|1:30 pm–2:30 pm
|Update core set of IHE-on-FHIR profiles to FHIR Release 4
Minutes: John: FHIR R4 Release
- The goal of the proposal is to align IHE profiles-on-FHIR to Release 4 of FHIR.
- The driver is ONC: they want revise their API specs saying that they will support only Release 4. (In particular ONC is focalized on US Core ( previously Argonaut Project) ).
- PDQm , MHD, QEDm , mXDE with priority (ITI will do QEDm… ). These priorities are due to the interest of ONC. We will declare success in our task if we will be able to update these specs. This does not mean that we will limit our intervention only to this subset of documents. If we have time and editors available, we can proceed on other profiles too.
- John had a meeting with ONC in order to discuss this process and in order to see if they are interested in our profiles, and they recognize the time needed to update our specs (they understand that we need some more time compared to the time needed to review a FHIR implementation guide). ONC asked IHE to provide time frame.
- TIMING: Release 4 will be published in January, we can start the review work by next week, looking into the build version of FHIR. John is deeply involved in the FHIR community, so it is confident that there won’t be radical changes from now to January. We should have a version ready for PC by the end of January. We will review PC during the next F2F in Treviso and we will hopefully publish a finalized version of all the profiles early March. This will allow us to test Release 4 during the april CAT in Rennes. However this is not a requirement. We can figure out this later with Lynn.
- Among different profiles listed as high priority tasks, MHD will require some work.
- Review process approach is still a pending question. We should discuss this in a dedicated sessione. Also Conformance Resources will be updated and the old versions will remain available to implementers. This will allow us to take a conservative approach with European connect-a-thon if things will move slower than the optimistic project’s timeline.
- John has been asked to find a reviewer for each profile (This will simplify the work for John). This will also provide “external eyes” to do a review of the updates.
- If the optimistic path will fail, we have a backup solution to move the approval for PC in February and resolve on comments in April. If we fail the short term we can stick with STU3 for EU CAT…
|2:30 pm–3:30 pm
|Add Feed transaction to PIXm (insert, update, link/unlink, and merge)
Minutes: Derek, Luke: Add PIXm feed transaction
- Luke will be the work-item editor, Daniel Berenzanu will be co-editor and Derek will remain engaged in the work in order to bring use-case needs.
- The needs are driven by multiple NHIS initiatives, in particular low-middle incoming countries, that wants to have a complete Patient demographic management infrastructure.
- The proposal is to add a new transaction (ITI-8 based on fhir) to the PIXm supplement, in order to fulfill the lack of a feed transaction. However, the cmte will prefer to keep this as a separate profile (this will requires further discussion), because [ITI-8] has a lot of implications with other systems (XDS Registry, MHD Recipient, MHD Responder, etc.).
- Merge functionalities is an open item with the goal to find a functional equivalent way to XDS.b and PIX. The behavior of the merge is needed for sponsors of this work-item because the Patient manager needs to interact and affect the health information exchange.
- There seems to be still a lot of question about the scope of the proposal, and we should try to formalize in detail the scope. Derek will participate on this for technical requirements and in order to grant that the output will meet initial requirements. The engagement of Derek will be also important when the cmte will ask for a reduction of scope.
- The gaol of the proposal won’t be the mapping with HL7 v2 messaging (OUT OF SCOPE).
- The following use-cases are included in the work-item: Creation / Link / Unlink / Update / Merge of Patient resource.
|3:30 pm–3:45 pm
|3:45 pm–4:15 pm
|Add RESTful feed to ATNA
Minutes: RESTful ATNA Feed
- The goal of the proposal is to define a standard transaction that allows a system to send an AuditEvent Resource to an ATNA Audit Record Repository.
- There are some mapping issues not addressed yet when we have to produce an AuditEvent starting from an ATNA syslog message, and this mapping shall be loss-less. This will be the main scope of the profile. Another point will be to define how apply this to all the IHE transactions that mandate [ITI-20] requirements.
- The proposal could be addressed in many different ways: new option in ATNA, new profile, etc.
|4:15 pm–4:30 pm
|Review, homework, agenda updates
|4:30 pm–5:30 pm
|JOINT PCC ITI QRPH RADIOLOGY
- Michael: asking about a PCC namespace and how it should be documented.
- john Stamm: Update on process for IHE getting new SNOMED codes (Chris Carr)
- Continuos Development?
- what's goingo on on FHIR? what about Release 4? John Moherke can report about these topics.
- Elliot: ask sponsors about updates on meeting locations for February and April.
- Information on the Care Plan Track at HL7’s FHIR Connectathon 2019, which Emma Jones is involved in: woki CarePlan track
- Project Gemini Project Proposal, which Chris Carr shared: GEMINI