NOTE: All content from the September 2022 HL7-DEV WG meetings below is pre-Approved. Please review and edit or update as needed - formal approval to occur at January 2023 HL7 DEV WG meetings.
Monday Q3, 1:30 PM - 3:00 PM (Eastern Time - ET U.S.)
Welcome, Introductions, and Agenda Review (HL7 DEV Officers)
ANSI Anti-Trust Policy reviewed: (Garguilo)
Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).
Garguilo walked through meeting minutes, no further discussion occurred.
Motion to "approve May 2022 Meeting Minutes"
Approved 16-0-0, First: Todd Cooper, Second: Ken Fuchs
HL7 DEV Meeting Coordination / Communications (Rhoads)
Use of HIMSS Teams or HL7 Zulip: The Missing "Chat" Window!
ACTION:John Rhoads John Rhoads to work with Sarah Bell (IHE) to get resolution
…To include Call canceling / change notification / etc.
Co-Chair Elections (No Co-Chair positions presently up for nomination)
HL7 Device WG - Future elections of six co-chairs to fill the positions currently held by Todd Cooper, John Garguilo, Martin Hurrell, John Rhoads, Chris Courville, and Martin Rosner (all of whom may be re-elected)
No further discussion needed.
Break 3:00 - 3:30 PM
Monday Q4, 3:30 - 5:00 PM (Eastern Time - ET U.S.)
Housekeeping: Current Versions of WG documents, for discussion (Rhoads)
A new metric has been added to Work Group Health measuring the number stale issues your WG has in JIRA across product families. Since this is new, it is purely informational at this time, but eventually anything in the red zone will result in an increment on your work group health. This metric will be recalculated before each report is released.
See links to current "HL7 WG Health" documents at end of this Agenda
Noted that Co-Chairs will attend the Q5 Co-Chair Dinner meeting - with a report out on Wednesday Q1.
John Rhoads Work with IHE Sarah Bell to resolve "MS Teams" Meeting chat issues
John Rhoads Validate latest versions of WG documentation, including this session's worked-on SWOT
Welcome, Introductions, and Agenda Review [Kosta M./Ken Fuchs]
Welcome by Konstantinos Makrodimitris (Kosta) and Ken Fuchs (Chair Stefan Schlichting regrets for first part of meeting) to in-person and virtual attendees.
Ballot to approve the resolution for extending the PAR for 10101b, approved last week, and start the SA ballot as soon as it ready. Deadline is the end of September '22
Recently went through a set of PHD revisions and extension for those standards - 104xx
09:15a | Agenda Review [Kosta] / Review Previous Minutes and New Members [Kosta]
Kosta walked through the IEEE-SA site, and showed the structure (tabs) for this PoCD WG.
Kosta reviewed the May 2022 meeting minutes taken, showed suggested edits to date, and asked for folks to send any other edits.
No further edits suggested by attendees.
Motion "to approve the IEEE-SA May 2022 meeting minutes" by Ken Fuchs, second by Javier Espina, no abstentions, no negative, passes unanimously, minutes approved (19 Attendees).
Tom noted there are several projects coming to deadlines in 2023 and suggested members have a look to determine what if anything needs to be done for that project.
Standards Breakdown presented.
Tom provided slide set providing breakout of IEEE 11073 PARs, Projects, SDOs
Current Projects Breakdown was provided
Noted that several above (e.g., P11073-10720) will likely need to be extended, as they are just started and in draft form… Martin K. noted that all of the projects are being worked on, although funding for projects has ended, members are committed to continue work. 2024 would be more realistic. Tom T, noted that if group could get to Ballot Stage (forming ballot group - at least begins by Q3 by 2023) there likely wouldn't be much push back from NESCOM to continue extension… Ballot should be at least ten individuals. Martin K. noted that it might be difficult to start the ballot by Q3 of 2023… Thus it might take 1-2 years. Tom suggested any time next year would be fine.
-10107 (External Control) has not had an progression. Todd Cooper suggested Mod Specs would be needed prior, but Bjorn A. suggested not the case. Bjorn suggested that group likely could get all to ballot about the same time…
AAMI remote control work / standards is coming from a slightly different angle...
Martin K. noted 10107 - regarding nomenclature - a few hundred terms to cover all aspects of work…
Standards and SASB Expiration Dates:
Presently (as of 16 September 2022) for PoCD
7 Active
6 Inactive-Reserved - can remain in this status indefinitely, unless requested to withdrawal
Malcolm Clarke noted the Inactive-Reserved were agreed upon to keep all in Inactive-Reserved
PHD standards
Presently (as of 16 September 2022) for PHD
Active 15
Inactive-Reserved - 6 - can remain in this status indefinitely, unless requested to withdrawal
Expiring at end of year: 7 (Note: Chart shows Dec. 2021, should show Dec. 2022)
IEEE MOUs in place:
HL7 - update to agreement being worked on...
LOINC
NIST - Royalty Free Agreement - will be reviewed for potentially adding additional information to be freely released as part of the new RTMMS System
ACTIONJohn J. Garguilo and IEEE-SA Liaison Tom Thompson to work on this before January 2023 meetings.
Update from SDC SG (Martin Kasparick, and Bjorn Andersen, now both with Draeger)
PHD Update (Daidi (not present), Ray Krasinski/Philips Healthcare, Isabel Tejero/FDA)
Ray Krasinski provided an PHD update
Spirometry - specialization, fourth round
10206 ACOM is now completed and in process of being published
ACOM spec does not ??
Battery status monitoring chosen (in the healthcare domain).
Kosta noted FDA has a program on "battery work group" (referenced Isabel Tejero)
Break 10:30-11 AM
Start Q2 (15 in person + 6 On-line (Martin K., Malcolm Clarke, Grant Forrest, Isabel Tejero, Stefan Schlichting, Jingu Choi)
Update from SDC SG (Continued)
Martin Kasparick subcommittee chair, introduced topic and provided information on progress of PKP standards
Bjorn provided an overview of the "Cathedral Window Diagram" (see above) and walked through the status of the included standards…
Started with the Key Purposes Standards
Device Specializations have much content, building on the PKPs and will likely have to extend to progress to ballot stage.
Coding System Box is left for Paul Schluter related to 10101 update (Nomenclature)
SDC is fairly flexible regarding code systems…
In addition to -10101, LOINC and SNOMED CT are primary, but not limited to these…
Not required, but encouraged, to use standardized terminology
Top box - "Profiles" - IHE SDPi profiles are the 'bindings' to the standards.
Noted that don't wait to implement, and start - there will (most likely) be continuous iteration and updates…
Question from Todd Cooper:
Question about ModSpecs and a consistent way to handle conformance (e.g., ICS Tables). Bjorn suggested that likely would be similar to the Base Stds ICS tables… claimed conformity, versus "approved conformity" - this would provide structure for conformity claims (and that they can be verified…
Martin noted the 'yellow' part they are waiting on the PKP standards, the other standards are continuously being worked on (every two weeks) Note: The plan is for adding the first two PKPs (working draft) by end of year or beginning of 2023… to share w/ international community
Considering joint development process with ISO…
Reference links for General Project, Issue Tracker, and Draft Document:
Vote on 1070x PAR Scope Change Proposals (Ken Fuchs)
10700 Scope was modified (Ken showed document - Redline from June 2021)
Proposing to do the same on the other scopes (e.g., base, metric, alert, external control PKPs)
Ken marked up these documents and restructured the working in a similar fashion as done for the 10700
Proposal on the table is modify the scope to bring into alignment with BASE PKP.
Question if this effects the NESCOM timeline?
Tom Thompson noted it depends - one can't expand a scope, but can edit it if still within the original scope. This is up to the Ballot Group… If the PAR is updated, and someone notes the change, that comment would have to be addressed for resolution…
For Metric, Bjorn agrees, but asked as for the Alert and External Control - is now a good time?
Ken responded that team (within Draeger) wants to limit this to human control…
This is up for discussion within working group…
Question as to if a vote is needed if just in the Base PKP, as those documents are still under development, and later hold a vote on Base + Alert + External Control
Update from the IDCO SG (Paul Schluter, for Craig Reister)
Standard has been extended to include lots of additional content
Document is now fully updated to meet existing standards for Implantable Devices
The Standard is moving forward to ballot will soon be available to wider public for comment…
Presently going to ballot group (extension was filed through end of 2023).
Sarah Bell, from IHE-DEV, can send notices to folks who ask…
Focus on P11073-10103R - Implanted Devices Cardiac
Kudos to Craig Reiser (IDCO group lead, BSCI), Paul Schluter (RTM Lead), and Michael Faughn (NIST) for help and expertise on the terminology development
Update from the 10101b (Paul Schluter)
Major extension of nomenclature - approved two years ago, and now an ISO standard… new amendment is 280 pages
Paul noted work in conjunction of work with RTMMS (Version 2) , via NIST Royal Free Agreement with NIST + IEEE-SA
Work in this field is still focused on can we eliminate "false positives"…
12:00-12:30 pm
11073 Stories/Pilots and Conformity - FDA/CDRH ASCA presentation: Simon Choi, Scott Colburn (Anil, Kosta, Stefan, Sajjad)
Scott Colburn/FDA presented the following material (several slides captured for notes):
Over 1400 Recognized standards
What is Recognition:
ASCA Program - Pilot and Volunteer program
FDA does not want to be restrictive, but understands the need to be sure technical assessors understand how to test…
What would a "summary report" include and look like… to get at conformity... 5 Accreditation Bodies Test Labs: 90 - not limited to USA
Device Compatibility 60601, 6060x
Is there plan for extension… how FDA will do this is still up for debate - developing the 17025, accreditation bodies…
Not trying to get all standards into notified bodies or additional costs to end user
Trying to more consistency and quality of testing - high quality date and declarations of conformity…
Questions Scott mentioned to consider:
What type of enhancements would be needed? In addition what ASCA has done to date…
Are the standards that are develop lend themselves to conformity
Trying to build regulatory ready - but understand some are
60601 and compatibility… more mature so FDA thought this was a good place to start…
Looking to do this more collaboratively beyond FDA - with SDOs, experts, domain groups… but not there yet… but FDA would like to engage more in the future…
What question are we trying to solve by putting it into ASCA… what are we doing to up the ante into the 17000 series…
12:30-1:45 pm | LUNCH
Nomenclature - Continued (Paul Schluter)
11073 lifecycle from cases, development to recognition to adoption to value for patients (Kosta, Stefan, Sajjad, Todd, Ray, Isabel, Martin, All)
Provide care where the patient is, not the medical devices
Alarm providers (at patient bedside) can stay silent - but signaling of alerts (e.g., to central station) to caregivers …
Use cases - Medium care patients… maybe wirelessly connected… usually want to see information from not only alert, but associated information on the patient that related to alert (or giving context)…
"Medium" - each hospital calls level of care differently…
WE HAVE WRITTEN A SERIES OF MANUSCRIPTS THAT DOCUMENT THE VALUE CREATED BY REAL WORLD EVIDENCE
THIS BUILDS ON THE WORK DANICA SHARED, ON COORDNIATED REGISTRY NETWORKS.
11073 to FHIR/PHR/EHR: how to integrate, map, coordinate medical device data for high quality clinical data and analytics (Kosta, Isabel, all)
Break 3:00 - 3:30 PM
Presentation on AAMI/UL 2800 (Geetha Rao)
• MOU between AAMI + UL about 10 years ago…
• Latest version release earlier this year…
Geetha noted that no action items identified regarding editions above however documentation efforts continue...
• Goal was to create a framework usable by a range of stakeholders. • Standard written "stakeholder agnostic"
Multiple "use specification" for "context of use"…
"Hazardous Condition" -
PoCD WG organization, meetings & wrap-up
Logistics next WG meeting
IEEE-SA 11073 PoCD likely to meet again jointly at the next HL7 WG meetings scheduled for January 16-20, 2023 in Las Vegas, Nevada, USA.
Kosta noted the potential going forward to have (off-cycle with HL7) IEEE-SA 11073 only meetings in 2023 - TBD...
4:30 pm Closing and Adjourn [Stefan/Kosta/Steve]
Note: Christian Haye was recognized for his fine work over many years - as he announced this would be his last HL7 WG meeting - Thanks Christian and all the best in your new endeavors
Motion "to adjourn the meeting": made by Christian Haye, second by Bjorn Anderson
Approved 16-0-0
CHAIR: STEFAN SCHLICHTING, PHD
VICE-CHAIR: STEVEN DAIN, MD
SECRETARY: KONSTANTINOS MAKRODIMITRIS, PHD
No Additional topics bought forward for (spillover meeting) this coming Friday morning Q1 meeting ( )
Kosta thanked attendees , reminded presenters to post slides.
Welcome, Introductions, and Agenda Review (HL7 Officers)
ANSI Anti-Trust Policy read to attendees (Garguilo):
Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).
Reviewed Monday Q3/4proceedings(@Cochairs)
No addiontal or changes of Agenda items (from Monday Q3)
Confirmed joint with O&O on Thursday Q1 with "spillover" time available on Friday Q1
Confirmed joint Thursday Q3 with Mobile Health WG and presentation of Laurie Whitsel from Physical Activity Alliance and the American Heart Association
Report-out by Co-Chairs of Monday's Q5 meeting ...
Association Management System (AMS) - Fonteva
Starting Monday, October 10, the transition to the new Association Management System (AMS) begins
As part of the transition, all updates and changes to the current system will be frozen. For more information on the systems that will be impacted check out the HL7 Fonteva Transition Confluence Space and the latest communication sent October 4, 2022
During the freeze, the HL7 Conference Call Center will NOT be directly available to you for scheduling, updating, or canceling calls. If you need to make such changes, please contact webmaster@hl7.org during the transition. All call information will remain viewable to the community on the website throughout the transition. The Fonteva implementation will go live before October 31, 2022 at which point the Conference Call Center will be accessible for self-service updates again
Thank you for your patience as we migrate to the new system. If you have questions, please contact Melva Peters at melva@hl7.org
Main Website Updates...
Production UTG GitLab
Logical Sandbox
New Ref. Implementations
HL7 timeline/plan - International 3-year plan (soon to be available...)
hl7.org/xprod/FHIR -
HL7 considering multi-language products (W.H.O)
Unified Terminology Governance UTG/THO
Considering 3 releases per year (each frozen 6 weeks prior t ballot content deadline)
R5 freeze / Feb 24
Graeme noted there are many many IG submitted, and asked only serious IGs should be submitted due to resources...
FAST transitioned from ONC → HL7
UCSD/UT FHIR Education Series available on-line (10 recorded sessions)
No Action Items for HL7-DEV (other than resolving and staying on top of Workgroup Health items)
PHD Status update/report out - (Martin Rosner, Erik Moll, Javier Espina)
IEEE ACOM and BT Generic Health Sensor update (Erik Moll, Javier Espina)
"ACOM and GHS - A unified model for personal health device communication - Supported on BlueTooth LE" presented by Erik Moll (Philips Research)
Personal health devices are abundantly available in most markets and are quite often connected and come with an application running on a smart phone, a tablet or sometimes a PC.
In most cases Bluetooth (Low Energy) is used to connect these devices. Sometimes USB, Wi-Fi or cellular connectivity is supported.
For remote patient monitoring, personal health & fitness tracking and many other use cases it is desired to integrate data from such devices in one place, one service for the patient or user.
Today, September 2022, there is still no good, generic, interoperable standard solution for personal health device communication.
As a result, for each PHD dedicated software is needed in devices, apps, gateways, servers => costly!
The suggested Solution:
HL7 FHIR:
–The healthcare IT world is moving towards HL7 FHIR as the application-level language to achieve interoperability of healthcare data in and around the hospital.
Regulations in US and EU require healthcare IT systems to open up their data via a FHIR interface
This helps a lot but does not yet solve the PHD communication diversity and that is where ACOM comes into play.
IEEE 11073-10206 ACOM:
ACOM stands for “Abstract Content Model”
ACOM defines a model based on the IEEE 11073 Domain Information Model (DIM) and nomenclature standard for medical device communication
ACOM objects and attributes map 1-1 to HL7 FHIR resources using JSON or XML.
ACOM is implemented in a binary protocol on Bluetooth LE – the Generic Health Sensor profile and service (GHS).
ACOM can be used by cellular IoT health sensor devices using a binary or JSON format
Within various working groups of IEEE, IHE and the Bluetooth SIG we developed the ACOM specification and protocols using it.
Todd Cooper asked how ACOM is "constrained" from POU Profile?
Eric responded that ACOM is constrained - stripped out attributes that are not used...
ACOM + FHIR
Build once
ACOM + FHIR enable a generic solution to connect sensor devices to apps, gateways and to cloud services
Extendable / flexible solution
Sensor types can be added without coding in apps / gateways / servers
The set of supported Observations can be extended without coding
Many device types / specializations are defined already in IEEE 11073 in an ACOM-compatible manner
Enables an end-to-end ecosystem
Based on one conceptual model of health devices and generated observations using a recognized nomenclature system
Suitable for [personal] health sensor devices at home, in the hospital and elsewhere (health & fitness, elderly care)
Erik presented IEEE 11073-10206 - ACOM basics (see slide 5)
ACOM Observations (Slide 6)
ACOM Observation mapped to FHIR Observation resource (slide 7)
Bluetooth GHS GATT profile and service specifications:
Question asked, how are you mapping compound observations? Separate Observation resources, Contained, Bundle, Observation.component etc?
(Response) ACOM is more in alignment with FHIR than in the past (components in FHIR <--> ACOM)
(Q from Todd) Payload encoding? JSON? -
(Response) Erik noted experiment was done encoding in JSON (was done internally) - there was also binary encoding for time stamps, etc… noted BlueTooth is not supporting JSON - as interested in more compact encodings…
Erik also noted that FHIR has a large footprint/code - not sure yet if efficient to be a standard alone…
On Bluetooth side, binary is used; the above diagram in prototyping stage… Bluetooth SIG require at least 3 implementations to communicate and test using the existing test suites…
Next event upcoming in Miami
Philips ACOM/GHS prototypes - used for testing:
Erik's summary:
We introduced the IEEE Abstract Content Model for Personal Health Devices – ACOM in the context of HL7 FHIR-based healthcare systems:
ACOM solves a big interoperability problem and enables an ecosystem of connected personal health devices, apps, services
The Bluetooth SIG Generic Health Sensor service and profile specification support ACOM on top of Bluetooth LE.
Some details:
IEEE 11073-10206 - ACOM defines a generic model for personal health devices and the observations these devices can generate
ACOM objects in this model can easily be mapped to FHIR resources
The Bluetooth Generic Health Sensor service and profile are based on ACOM and are in interop testing phase in the SIG
ACOM and GHS enable build-once gateways to get PHD Observations into FHIR servers GHS demonstrators and source code are available on Android
Question asked about Open source and proprietary...
Can you explain the difference between Continua certified and ??
(Response) Stack did not find grounding in market due to complex state machine… took information model out of this and aligned more with FHIR and this is what ACOM would be
Todd asked about a FHIR-based project out of Univ of San Francisco…
Jacob tried to map the 'complicated pregnancies' use case to FHIR;
Noted a very complex use case to address… not aware of all FHIR constructs available
COVID-19 use case:
Holter monitoring: can't yet share details, but in some cases Holter monitor can be connected and do a live streaming - also looking to do a large roll out...
Live Spirometry flow, so not to wait the 6+ seconds to do a live flow…(waveforms)...
Two issues:
1. Complex nature of date (mapped to IEEE, and in particular to FHIR) - lacking more complex data types, as well as some quality enumerations… e.g., when leads are not connected properly - there is noise ratio
--should have some attempt to get a consistent way to do this in FHIR
2. Live Streaming - more generic way to do this w FHIR payloads - send data to server, viewer that pulls date from server in real time or near real time/recoding while being made…
Todd Cooper noted is useful in Zulip to capture the use cases…
Paul Schluter commented that work was done regarding waveforms… reasonable for real time monitors - including beat to beat etc. (this was done in HL7 V2)… Can be easily persisted as a binary data set (V2 can be trivially mapped to be looked at retrospectively later on…)
Mikael Rinnetmaki (Finland) - added comments around timing intervals - e.g., medication requests… Once you do this you end up with a bundle around 20-30K which are sent to server, and then accessed (this takes 20 - 30 minutes - which has big consequences…) - now becomes 30 minutes back which is obviously not ideal… Could a sample bundle be published as a FHIR resource to highlight this issue… Sample data is available, but not yet on the explanatory text… this could be discussed on one of the weekly Monday or Wednesday 9 am Eastern US meetings… where do pieces fit and try to coordinate this…
Suggested to coordinate via Zulip… Slides to be sent at later time… perhaps when more details written about the use cases… Jacob agreed to send once available…
EEE EMBS Standards referenced
IEEE 1752 noted...
Breakfrom 10:30 AM - 11:00 AM ET
Wednesday Q2, 11:00 AM - 12:30 PM (ET U.S.)Room "Watertable B"
Discussion on the challenges or (several) ways of recording a setting -Device Metric
There are gaps -
ACTIONElliot Silver Begin to capture the use cases identifying (and ultimately addressing) such gaps...Type your task here, using "@" to assign to a user and "//" to select a due date
Use Cases - both that are distinct to a specific use context and that involve two or three and require cross-context coordination
Use Contexts - are the (3) suggested appropriate or should there be a further breakdown? Architectures?
Ecosystem – Intra & Inter Context Providers / Consumers (e.g., EHR consumers of PoC device content)
Risk => Criticality => Regulatedness: Clearly this is involved in all three use contexts, but at different levels?
Quality – including process requirements (e.g., ISO 13485)
User - professional clinician to personal grandpa or family caregiver
Technology - esp. with the advent of Medical IoT & Clinical IoT and Io<everything>T, mobile FHIR-based, AI/ML MD ... EMBS SC initiatives? Etc.
-Consider RWE needs of FDA and others @ AI / ML MDs ... melding a few of the above aspects
Architecture – Is there a clear delineation between device subsystems that allow for "containment" of critical (high risk) functions to one system component (e.g., the dialysis subsystem with SiMD) and other elements, such as education or user interface to software applications (general health software & SaMD) that are running on a general purpose platform?
Communication Devices:
e.g., mobile "device" - "device used in a clinical setting" but not a regulated medical device (at ACM: Edge devices / end-point communication devices)
Google Glass ... VR / MR / AR technology
Note: in ACM a "dashboard" can be an endpoint "device"
Connected vs. Disconnected (not connectable)
HIT Infrastructure "devices" vs. health / medical purpose (sensor/actuator/intelligence) "device"
Including ID & location devices (e.g., RFID)
Cameras ...
e.g., for patient assessment in an isolation room
Martin Hurrell suggested to first make a general list that "everything people might consider to be a device, and that people are interested in:… but something like a multi-lumen catheter is of interest..
Write down as many "real" devices that we can
Try to define a series of constructs in which could be used to define - such as can a device communicated, etc…
Look at tirade of these devices to say in what way are these devices alike, but others do not…
Constrain it "medical devices"
Potentially look at multiple set of devices…
OO has a much broader space (beyond Med Devs) - this may hinder the need for this quickly…
Perhaps find out what O&O considerations / exemplars are?
Importance is high
Timing: hard to say how long this would take…hard to say??
Goal would be to make a significant improvement on where we are now…
ACTION: @Todd Cooper and @Martin Hurrell: Re-start the Technical Report process for "What is a Device?"
Todd Cooper started a new project (ID: PSS-2120): Added to O&O Agenda for Thursday's Q1 discussion.
Considered leveraging the "What is a 'Device'?" metamodel mentioned previously to explain what is unique about the alerting devices & DEVAL space but without having to include the whole topic (again,linkablearticle)
DISCUSS: (John Donnelly , not attending meeting) Alert Policy
Should the DeviceAlert project also include something around a care provider's "alert policy"?
By analogy, security experts who see "risk management" as 100% a security issue, always talk about managing security policies
Medical device alerting includes similar policies; however, they are never formalized (via standards) and are definitely not computable
This is a similar concern to the ISO/IEC JWG7 "SES" concern and is tied in with requirements from 60601-1-8, 11073-10702, and similar standards
Alert management systems (DIS / DAS / cDAS etc.) all include support for configuring in accordance with implementation environment polices, e.g., around escalation BUT ...
Is there value in making this COMPUTABLE (as is the case with security infrastructure) and if so, how?
ACTION:John Donnelly John Donnelly to provide use cases around Alert Policy
Review general "heads up" content proposed for the updated Device resource description
Review the content being added to the SDPi 1.0 TF-1 front matter related to the scope of the IHE DEV TF (this will be the first version of the broadened IHE domain (vs. PCD only)
Discuss whether and who and where to include and publish the broader question of "What is a 'Device'?" material
Consider Martin's work around establishing a metamodel w/ attributes, looking for "clusters" and leveraging that to address some common uses of the term: device
Determine the best place to publish this article - for example as an article in the FHIR space similar to workflow and other topics (andlinkablefrom the device-related resources!)
A previous project proposal (pre PSS) was floated for this topic but never fully advanced .. should it be now?
All in favor of Dr. Martin Hurrell being the Editor-in-Chief, raise your hand! (you cannot vote, Martin ...)
Martin Hurrell asked to defer his taking this item on...
Is this a Gemini (joint IHE-HL7 article) and should fly under that flag? Or simply an HL7 internal paper? (it will be used / leveraged in the IHE DEV TF-1 discussion)
(Todd Cooper) MDIRA Project Update (esp. relevance to SDPi + EP group discussions)
Introductions: 13 Attendees; new attendees for Q1 Grant Forrest, Dr. Cheryl Lohman, "SV"(?)
Garguilo read ANSI Anti-Trust Policy:
Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).
In process of publishing technical paper (likely Oct/Nov '22??) - would include a collecting of things/activities pulled together...
CDC referenced...
UMHAI - PSS-1867
Plan is to release draft next year
Static and dynamic IDs - some devices
How would it get managed? need to be unique!
centralized registry - how centralized??
Security managed??
Maybe similar to IP addressess?
Others...
2:30 PM Meeting Session w/ Physical Activity Alliance and the American Heart Association - continuation as they jump into the HL7 FHIR standards development world
Laurie Whitsel (Laurie.Whitsel@heart.org) and Maria Isler (Maria.Isler@heart.org) are the project sponsors. Project Proposal for an IG defining standards for physical activity measurement and enhancement.
Specifically, the project is looking at being able to capture measures related to physical activity level. This may well involve leveraging real-time device information such as step counts or heart rate monitor information.
Laure asked to please think about if/how the HC Devices work group might like to be involved.
Also reaching out to PC, FM, OO, MH, CIC, and the Gravity project
PAA will continue to meet with DEV as part of the Q3 joint meetings with Mobile Health moving forward (and at January 2023 WG meetings)
Thursday Q4(3:30 - 5:00 PM)Room "Watertable B"
Open Discussion / Topics Arising from this week... (Co-Chairs)
Considerations about future IEEE-SA PoCD WG 2023 Meetings (hosted by FDA)
Regulatory map/coordination on interoperability
Encouraged attendees to propose HL7 DEV Topics for next meeting...never too early to get them on the table
Action Items overview going forward from September 2022(HL7/IEEE/ISO) andcoordination with other SDOs
Action Items Review (deferred to once meeting minutes completed)
Planning January 16-20 '23 WGM (Co-Chairs)
HL7 announced it will likely be a live event in Las Vegas/Henderson, Nevada
Feedback from these/September '22 meetings
Objectives / Core Topics for January '23 (incl. joint sessions)
NOTE: we have been offered a full Quarter with OO - continuing to assume Thursday Q1 works best for DEV(?)
Attendees agreed
HL7 Room Reservation for January 2023 Meetings (Garguilo)
John J. Garguilo (Completed ) ACTION: Garguilo to reserve rooms and schedule joint quarters - needs to be completed by next week.. .To include full Q with O&O and DEV (OO hosting); Q3 Thursday with Mobile Health WG and Physical Activity Alliance
Meeting Adjournment (Co-Chairs)
Many Thanks to our thoughtful presenters, attentive attendees, and a VERY Informative work of week!
Co Chairs thanked participants and presenters for their engagement, enlightening and very informative sessions throughout the week and contributions to the HL7 DEV WG :-)
Attendees reminded to review these meeting minutes and post all presentations to DEV's Confluence File Storage Area within Working Group Materials Folder (or send to John J. Garguilo
Be well and thanks for your attendance and work as we move DEV forward :-)
Hope to see everyone in Las Vegas, Nevada in January 2023!
HL7 DEV September 2022 (Baltimore) Meeting Adjourned at 4:45 PM, Thursday September 23, 2022
1 Comment
Elliot Silver
Submitted FHIR-38917Add example of and/or guidance on how to associate device settings with clinical observations to capture device settings/clinical observation correlation issue.