Monday-Q3: Meeting Notes

• Introductions
• Agenda review

Administrivia

• • Project insight:
    • 1095 – LRI Functional Model
      • STU extension (need to check that went through) and then adjust based on LRI publishing
      • Plan for an informative ballot?
      • Set milestone to May 2023
    • 1700 – IHE SDC
      • in ballot reconciliation
      • next milestone Jan 2023
    • 1742 – At Home
      • in ballot reconciliation
      • next milestone Jan 2023
      • remove the '??' in the beginning of the description;
        • PSS-1892 has none, but the description is different
      • Can’t seem to find the project insight access to this – Hans Buitendijk to ask Dave Hamill 
    • 1068 -
      • no change
    • 1115 -
      • no change
    • 1756 – RBC Phenotype
      • John Spinosa PSS-1942
      • Motion to put this on hold due to lack of resources: Lorraine, Patrick, no further discussion, against: 0, abstain: 0, in favor: 8
      • Question to Dave: how does a project placed on hold show up in the jira approval process
    • 972 – LOI
      • Publication Request is on TSC desk
      • Milestone date Jan 2023
      • Project end: May 2025
      • Then we need to deal with Gender Harmony
      • Discussion around gender harmony data via lab flows (what if the patient walks in there)
    • 973 – eDOS
      • Requirements form this went into FHIR catalog
      • In the near future we should withdraw this
      • This STU expires in Oct 2022 - so we need to submit an extension request
    • 1010 – Catalog
      • Waiting for R5 to publish so it can be published
      • Milestone date May 2023
    • 1067 – laborder Conceptual Model
      • In ballot reconciliation
      • Next milestone: Jan 2023
    • 1292 – SpecimenDAM
      • Next milestone: May 2023
      • Want to keep it open till we have FHIR resources
    • 1294 - LRI
      • Publication Request is on TSC desk
      • Milestone date Jan 2023
      • Project end: May 2025
      • Then we need to deal with Gender Harmony
      • Discussion around gender harmony data via lab flows (what if the patient walks in there)
    • 1335 – LIVD
      • Milestone date Jan 2023
      • Working on getting this published
      • Project end: May 2025
    • 1370 – Transfusion
      • No answer from Bob Milius
      • Motion to put this on hold due to lack of resources: JD , Patrick, no further discussion, against: 0, abstain: 0, in favor: 8
    • 1481 – V2-FHIR
      • Making slow progress
      • This is getting use, since we are getting questions 😊
      • Still a red PBS metric, but nothing much we can do about it
      • Milestone date Jan 2023
      • Using the latest version of FHIR
      • Project end: May 2025
    • 1496 – DME
      • Still in ballot reconciliation
      • Milestone date Jan 2023
    • 1539 – Lab Model
      • Milestone date Jan 2023
      • Put this on Thursday Q4
    • 1614 – nutrition DAM and FHIR
      • Milestone date May 2023
      • Resource updates are in R5
      • Completing the DAM reconciliation comments
    • 1634 – AOE Crossparadigm
      • Preparing for ballot
      • Milestone date May 2023
      • Add to Friday lab call topics
      • End date Sept 2024
    • 1686 – Cancer Pathology
      • In publication request
      • Milestone date May 2023
      • End date Sep 2025
    • 1541 – Vital Signs
      • Need to check if the must support changes were done in R5
      • Approved for publication
      • Check with CIMI

Monday-Q4: Meeting Notes

With CQI (not present), CIMI, CDS (not present)

• Agenda review
• ADI on FHIR report out – not discussed

CIMI project 1359 and 1541 updates

• • 1359 Lab Model Profiles
    • Work delayed, but still interested
    • Working on high level patterns (titer / coded / ) – worked with Graham on a library to create the subtypes for more specific LOINCs
    • Next Milestone date: Jan 2023 – to be updated Ulrike Merrick 
  • 1541 Vital Signs
    • Now published as STU1 for US
    • Now working on the universal realm with goal of ballot in Sep 2023
    • Next milestone Sep 2023 – to be updated Ulrike Merrick 
  • No topics for Thu Q4 – so update agenda to jira review

ISA review

• • https://www.healthit.gov/isa/isa-document-table-contents
  • Review for OO content to comment on:
  • TERMINOLOGY SECTION: 
    • Biologics = Biological Derived Product
      • Is there any other vocabulary we should propose?
      • Looking at the FHIR resource the product codes look like these are HL7 curated, but this needs to get updated to indicate that this is ICCBBA
        • Make a ballot comment in R5 to get this fixed
      • No comment to make
    • Clinical Tests (non-images / non-lab)
      • LOINC sounds good for the test identification
      • MAKE THIS COMMENT: For the values they should create a separate descriptions similar as they have done for “Performed test”– for coded results could propose use of SNOMED CT
      • Review again after we discuss use of CPT4 for lab as indicated by AMA
    • COVID-19
      • Why is SANER listed – check with Keith and Bryn @Riki
        • This IG does define a few code system (ADD LINK to supporting vocabulary code system)
          • Measure group system
          • Situational Awareness Measure population
          • Measured values system (CHECK ON THE NAME!!!)
        • Logica COVID-19 IG also defines one code system
        • COMMENT: ISA should update to link to the vocabulary in this space rather than just the full IG – same applies to the Immunization IG
        • Give the PH WG a heads up to look at this @Riki
    • Dietary + Nutritional Needs
      • COMMENT: ISA should update to link to the vocabulary in this space rather than just the full IG; the full IG should be listed under content/structure
    • Laboratory
      • Ordered test
        • CPT has been added at request of AMA
          • In 2021 request to include CPT
            • in LOI under ORC-16 – trying to catch up with Nancy Specter to find out what is meant there
            • why is this included here, since it is used for billing and not for ordering
          • Performed Test
            • No comment
          • COMMENT: ADD as separate category specimen and point to SNOMED CT
    • Vital Signs
      • Listing IEEE11073 under vocabulary
      • COMMENT: ISA should update to link to the vocabulary in this space rather than just the full IG; the full IG should be listed under content/structure or Services/Exchange – make this a general comment and use these as examples
  • CONTENT AND STRUCTURE
    • Diet and Nutrition
      • No comment needed
    • Lab
      • IVD data exchange
        • LIVD IICC – is there a cost? @Riki to check with Serge
      • Ordering
        • COMMENT: To update to the latest version of LOI
        • COMMENT: Add the AOE document here
      • Resulting
        • COMMENT: To update to the latest version of LRI
      • Catalog
        • COMMENT: Double-check which one was put into production and then suggest to drop the ones that are not
        • COMMENT: Second one is not really in production
      • Unique Device Identification
        • COMMENT – applicable to ALL sub points: Update UDI Pattern to list release 2 and probably update the production level, since this is being used as building blocks for implementation of other IGs in certified systems that refer to
      • Service/Exchange
        • Both Unsolicited push
          • COMMENT: add V2 as the base standard – no specific version or IG
        • Query
          • Not sure if we want to point to V2 Chapter 5 here?

USCDI V4

• • • USCDI V1 and V2 published and enabled in CCDA and FHIR USCore
    • USCDI V3 – published; will be enabled early 2023
    • Reviewing attributes if they have value and enough implementation that it should be added into V4
      • Level 2:
        • Biological Derived Product
          • Product Code
            • Have specification
          • Unique Identifier
            • Have specification
          • Source Identifier
            • Maybe this is the same as biologicalSourceEvent? – need to double-check – David Barlin – @Marti??
          • Division
            • Have specification
          • Processing Facility
            • Have specification
          • Not every HIT system has interest in this, so may not be applicable to many
        • Laboratory
          • Dates
            • This needs to be more specific
              • For sure would need the
            • COMMENT: put in ALL the attributes that are included in the LRI – OR AT MINIMUM ALL the CLIA elements
            • Specimen
              • COMMENT: at minimum need type and collection date/time; CLIA says also source site, when appropriate
            • Nutrition
              • Check with Becky
            • Observation
              • How does this relate to lab and clinical tests and vital signs?
              • Comments on V3 – see if there are any errors – Riki to review, think there may be something

FHIR-38635 – DocRef operation into base spec

• • Who owns this?
  • OO owns docRef, but who defines the operations
  • Looking at USCore Fetch Document Reference (ADD LINK)
  • For the Operation$ - on the patient ID that would return every resource available for a specific patient – that text is written on the patient resource page – need to talk with PA about that

Tuesday-Q1: Meeting Notes

• Introductions

Lab Conceptual Model Reconciliation

• • Reviewed proposed State definitions State Definitions 20220920.docx
  • Continued review of affirmative comments  HL7_DAM_LABORD_R2_I1_2020FEB_consolidated 20220920.xls

Tuesday-Q2: Meeting Notes

• Introductions

• Agenda Review

Table 0301 – Universal Identifier Type - similar to HL70203 (both owned by InM)

• • We do not have GTIN, GS1 in either of these tables

  • We need to make sure we align with FHIR handling of identifiers https://hl7.org/fhir/datatypes.html#Identifier

    • identifier.type uses the identifiertype code system (owned by Vocab) = https://hl7.org/fhir/valueset-identifier-type.html

      • this is also referencing identifier registry = https://hl7.org/fhir/identifier-registry.html

    • Ralf Herzog  will make a change request against V2

    • This is really one of the tables used across all product families, so maybe we can work on that with CDA 

    • Could we get this cleaned up as a R5 ballot comment - Ulrike Merrick  to submit

X-eHealth IG on Lab Reporting (Rob)

• • https://build.fhir.org/ig/hl7-eu/x-ehealth/StructureDefinition-Bundle-lab-xeh.html 

  • In Europe many countries are using CDA (IHE XD-Lab) for result reporting, but many governments wanted to migrate to FHIR

    • In EU they are working on exchanging lab results between countries

    • They are making updates to the XD-Lab specification as part of this project

    • Migration to FHIR – open question

      • Specification – FHIR Profiles

        • Bundle Laboratory Report (snapshot view)

          • They want to use the composition for this as he main entry, while OO previously has proposed to use composition only when structuring is needed inside the diagnosticReport

          • DiagnosticReport with cardinality 1..*

          • The bundle then also includes all the referenced resources separately (or discuss if we want these as contained resources, so that the diagnosicReport can be signed off – this is how Labcorp does this

          • Report as a whole needs to be signed, which is why this group decided to use composition, as that handles the signature

          • One option was discussed a while ago to create diagnosticReport as a profile on composition

          • In V2 we have the group of OBX segments – these don’t have to be used in order, but most often is – but we should not pertetuate

          • imagingStudy (covers DICOM metadata) and genomicsStudy (covers the pipeline info) but that does not cover the results

          • Use composition for structuring

          • Proposal: remove reference to observation in DiagnosticReport.result and allow only reference to composition

            • This is a breaking change, but we have not that many implemented AND all would benefit the approach

            • This needs more discussion with FHIR-I (and maybe Structured Doc)

            • Or do we just create a NEW resource or a profile on the resource

          • Option would be to make DiagnosticReport.result and backbone element (Dan + Rob H to write this up (maybe draft in CU build for discussion in FHIR-I for Thu Q2)

            • To add name (to allow giving it a section name) AND result.sequence (for grouping) which both are optional

          • Signature for the DiagnosticReport is needed (the report is the one that is being signed)

            • Suggestion was around using provenance in addition the DiagnosticReport

            • Composition has authenticator

            • Move this to FHIR-I discussion on Thu Q2

            • An IG can limit the performer to the releasing person (legal requirement to track back the)

          • Rob need to have some idea where we need to go ASAP, so we may need the long-term approach, but may also identify a short-term solution

  • Xehealth does not want to break the Belgium implementation: http://build.fhir.org/ig/hl7-be/lab/StructureDefinition-be-laboratory-report-composition.html 

    • Bundle contains section as 1..1 which an entry 1..1 reference to the laboratory report profile

      • A section can have another section 0..*

  • Create a list of the functional requirements:

    • Sequencing the observations in a diagnostic report is important

    • Signing of a diagnostic report (what is the reason for this signature – is this a legal construct

    • Break as few of the in-process or existing implementations if possible

      • If we break a solution we need to identify what the rationale is for that

      • The X-ehealth is an implementation on top of national profiles

Tuesday-Q3: Meeting Notes

Discussed Lab Workflow

Reference Links to content reviewed: 

• https://build.fhir.org/workflow-management.html
  • See Option F (need to rename this section)
• https://build.fhir.org/examplescenario-example-laborder.html
  • Create Order Sequence Diagram – provide the options in the Implementation Guide and the conditions for the scenarios/use cases
  • Accept Order
    • Need order acknowledgement (similar to v2)
  • Initiate procedure (discussed as out of scope of the lab workflow)

Reviewing other Implementation Guides to assess how the lab workflow information is being done currently: 

• E.g., DME IG

Need to handle "How to issue someone else a "Task" should be in a separate IG

Discussed that there are many variations to the order workflow across jurisdictions and the general flow should be described.  The Implementation Guides can give additional options/details for the variations as necessary.

Additional Use Cases/Examples (Add Jose's List - below in general capture)

• Order to a Specific lab, but change by patient
• Change to the Order Requested
• Tasks across Order
• Billing Tasks - sub-workflow

Will discuss high-level with II – Q2 Thursday-- the general approach for workflow; would like the examples of core to be generated from IG publisher.

Tuesday-Q4: Meeting Notes

• Agenda review

OO Dashboard

• • For each call we have dashboards with related resources that should be discussed:
    • Lab Dashboard
    • OOonFHIR Dashboard
    • Specimen Dashboard
    • HCP Dashboard
    • Nutrition Dashboard
    • Workflow Dashboard
  • Related artifact lists ALL the resources mentioned / associated with our workgroup
  • Resources can appear in different dashboards
  • This includes all tickets that have not been marked as applied
    • Need to decide how to deal with the ones that need to be applied – maybe just 1 for all resources on the main OO dashboard
  • Thanks to Marti we have those
  • This will be helpful to quickly see the summary
  • Looking at Lab Dashboard as example:
    • Still has summary and overview
    • Then for each resource we have a filter with issues
  • If you find broken filter, please email Marti

FMM level progression

• • FMM0
    • DeviceDispense
      • not yet – put this on HCP call
      • assignment to the patient
      • with medication messages in v2 there needs to be a concept of a dispense request and then an assertion that it has been dispensed – need to be able to track the resource at the
      • then we also need to discuss the delivery of the medication to the patient bedside (not yet administered) – does this fall into this
    • DeviceRequest
      • Note to balloters in R5 asks if this needs to be combined with SupplyRequest (unclear who submitted this)
        • Answer is NO, because it does NOT include the patient as the subject of it is used for inventory purposes, even if the requester and the delivered to can be a patient Hans Buitendijk  to enter the jira and all others can then vote on it
      • Work with Robert Dieterle  on finishing off the ballot reconciliation
      • resource proposal has been approved - see: DeviceRequest FHIR Resource Proposal
      • Make this FMM1
    • InventoryReport
      • Not yet
      • Was created on the logistics call on Friday, but nothing further
      • Keep in the OO-on-FHIR for the dashboards
    • Transport
      • Resource proposal has been approved - see: Transport Resource Proposal
      • Make this FMM1
    • FHIR-38665
      • Applies to DeviceRequest and Transport
      • Motion to find persuasive, enhancement, non-substantive, Lorraine Constable, JD Nolen, no further discussion, against: 0, abstain: 0, in favor: 10
      • Assigned to John D.L. Nolen 
  • FMM1
    • BodyStructure
      • Had several discussions with PC, CIMI, CIC, dev group for anesthesia, Vanguard IG
        • Need to test out how well the included and excluded structures component work – request them to do some connectathons so we can move this up @Riki to email Stan for this one
      • DeviceDefinition
        • Catalog and LIVD are both using it, but those are not published yet
        • Elliot is building an internal IG, so he can provide feedback
        • Leave for now
      • DeviceUsage
        • Nutrition used it for modeling nutritionIntake
        • Leave for now
      • NutritionIntake
        • Was just moved up last cycle, so leave
      • NutritionProduct
        • Ask the project team, but assume leave as is
      • ObservationDefinition
        • Used in catalog and LIVD, but those are not published
        • @Lorraine to ask Bryn if that is used in their plan resources
      • SpecimenDefinition
        • Leave as is
    • FMM2
      • BDP
        • Reach out to Paul Ashford, David Barwin, Karen Moniz, Hussein Ezzeldin, Barbi Whitaker to see if they want
        • Need to check the conformance Resource Quality Guidelines - Bring up on HCP Monday call
        • Need to make sure vocab is approved by HTA, when external or in THO
        • If we have some implementations, then it could even go to FMM4
      • Device
        • Can move up to FMM3
        • Need to check Quality guidelines – bring up on the HCP call on Mondays
        • Need to make sure vocab is approved by HTA, when external or in THO
        • Has been exercised in USCore for subset of implantable devices in FHIR R4
        • Should have coverage across 80% of the scope area so far
        • Talk to Devices –  see Thu Q1
      • DocumentManifest
        • There was proposal to take this out – Hans Buitendijk will ask FMG
      • NutritionOrder
        • Leave as is
      • ServiceRequest
        • Is used in BeSR, Gravity, DaVinci??, Ontario Referral spec, used for procedureRequest in PC, USCore 5.0
        • Bring up on Friday workflow call to check quality and vocab good enough for FMM3
      • Specimen
        • Specimentype is in USCDIv3 and in USCDI+ (collection date.time and source site) AtHome testing, CancerPath
        • Gino had a tool that shows which resources are used in IGs
        • We need to add more examples
        • This has not been tested for retrieval etc
      • Task
        • Has been used in many IGs, but probably not tested much
        • Bring up to FHIR-I on Thu Q2
    • FMM3
      • DocRef
        • Decided on 9/15/2022 that we will move this up FMM4 – see FHIR-38667, will check on vocab quality for sure
          • Motion to find persuasive, enhancement, non-substantive, Lorraine Constable, Patrick Loyd, no further discussion, against: 0, abstain: 0, in favor: 11
        • Assigned to John D.L. Nolen 

Mission / Charter Review

Draft:

Mission - No change

The mission of the Orders and Observation work group is to define information exchange capabilities to support the order/scheduling and clinical event management/reporting requirements between the stakeholders in the healthcare organization regarding patients, non-patients, people, other species, or inanimate objects. These information exchanges are not limited to intra-organizational transactions, but may cross organizational boundaries. These information exchanges may involve messages, documents, services, and other HL7 constructs.

Charter - Updated

• • Deal with Version 3
    • not really working on that
    • We are still working on domain analysis models, but those are no longer called V3
    • We do have informative nutrition V3 messages, so use “artifacts owned by OO”

The basic charter of the Orders and Observation work group is to continue to support the ongoing development of Version 2.x supporting critical regulatory and implementer requirements, support V3 artifacts owned by OO, and expanding the capabilities of FHIR, including current capabilities in v2.

Formal Relationships With Other HL7 Groups - Updated

• • Remove
    • Anatomic Pathology
    • Clinical Statement
  • Change
    • RCRIM to BRR
    • PHER to PH
    • Add V2 Management Group

The Orders and Observations work group has formal relationships with the following HL7 groups, in many cases as a result of V2.x and V3 content overlaps.

• • • Clinical Genomics
    • Devices
    • Imaging Integration
    • Patient Administration
    • Patient Care
    • Patient Safety
    • Pharmacy
    • Public Health
    • BR&R
    • Structured Documents
    • Management Groups

Wednesday-Q1: Meeting Notes

• FHIR-33394 - Need to get with Ricardo in Specimen
• FHIR-13047 - Need a call with Ricardo, John Hatem, Michelle/PC, (Paul Ashford), David Barwin, Karen Moniz.  HCP call.
  • General pattern for product ordering, "administering" for BCP and other non-medication use cases.
  • Consider dosage instructions on ServiceRequest further.
  • Included NutrititionIntake, MedicationAdministration, "BDP Procedure", etc.
• FHIR-33326 - Suggest to use Device for the use case at hand, with limited/no identifying information.  Also, add an example in Device to indicate why you would one or more Device instances even though you only know "type" information.
  • FHIR-38674 is new JIRA for Device
• FHIR-37975 - Hard to pre-adopt R5 resource as that is not permitted, but could build one on Basic that looks alike.
• FHIR-33389 - Seems to need to be on Procedure more so than Device, definitely not DeviceDefinition as it is about data in context of the procedure being performed.
• Specimen
• FHIR-38161
• FHIR-38657
• FHIR-32889
• FHIR-29793 - Needs follow-up

Wednesday-Q2: Meeting Notes

Jira tickets with II

• FHIR-38673 - Getting issue details... STATUS   - ImagingStudy references procedure

  • In DICOM this references the type of imaging procedure – match how serviceRequest.code is defined

  • We may want to have the planDefinition and procedure in there; not sure we have a good definitional resource for procedure

  • Ask the FHIR-I folks

Review of II related IGs

• • DICOM structured report to FHIR resources to later be available in the AI processing – see DICOM SR to FHIR Resource Mapping IG

    • FHIR resources are used in the AI IG

    • Mapping the DICOM structured report elements/measurements into observation profiles for each element

    • This uses R5 imagingSelection resource

      • is FMM1

    • Tested at this connectathon

    • Algorithm would use the device and parameters as child references to other device resources

    • Using observation.focus with reference to bodyStructure, that allows use of the DICOM

    • Profiles of imagingSelection to support the various types of image references used in DICOM SR measurement observations:

      • Referenced images / frames
      • Referenced segment
      • Referenced radiotherapy structure set
      • etc.

    • Aim is May 2023 ballot after January 2023 connectathon

    • In Q1 we discussed capturing data on how the procedure was being done and what would be how to document adjustment of calibration during the procedure – i.e. how to capture history of procedure

      • For algorthims may be just a new device, when something is changed, so you need timeslices of each device, but for AI self learning that may be a problem

    • Need to find FHIR-33389 discussed in Q1 and take that to radiology

    • We also want CG look at the imageSelection resource – add to agenda for Q3

  • FHIR to v2 and DICOM Modality Worklist mapping – see Draft IG Project Proposal - Imaging ServiceRequest Profile

    • Image Service Request Hierarchy

      • Can have one or more requested procedures (ServiceRequest) and those can have worksteps (discussion task vs ServiceRequest) leaning towards task, as we need to have the status element for figuring out which work steps are still open

      • Each of the ServiceRequests have tasks have a protocol associated with it – how would you indicate the protocol used – should maybe be referencing an activityDefinition

      • That is similar for lab automation – but that has not really been discussed yet either

      • Tasks should know the ServiceRequest they are basedOn

      • How to differentiate between Top level ServiceRequest (is a parent) – category imaging and the lower level where you may want a subcategory – can create codes for imagingProcedure and subtask maybe (this could be built as hierarchical code system

      • OO has interest because of Digital Pathology – IHE has just published first draft in V2 for DIPA (based on LAW) – both have push or query option is there value to build this in FHIR, or if folks don’t want to use v2 just use DICOM for that?

      • Maybe we should make sure that modality worklist = i.e. what do I need to do (and have parameter list of subject – for image, for specimen, for procedure, for care etc) – this may also be for AI is generalizable

        • The AI orchestrator will be orchestrating that = IHE radiology has this in a profile, the parameters are based on DICOM unified receiver steps (not implemented much) rather than DMWL using RestFUL service

        • IHE also has AI results profile which allows for DICOM and other types of output like FHIR

      • Project proposal will be reviewed with DICOM WG 6 and then put this in jira – suggest to also make DICOM WG 26 = Digital Pathology aware - IHE PaLM is working on so they will also have interest

      • We have to deal with the workflow around the results as well

        • The observation will need to have context; dealing with unsolicited FHIR resources etc

      • Want to model what image observations look like regardless of where they are coming from

    • Alex Goel  will share his sample activity that generates a serviceRequest for Chest X-ray with II

    • Alex Goel  can be the OO liaison to II

    • Keep this quarter for next WGM

mCode Cancer-related Surgical Procedure

• • • using this in the Cancer Path IG to define what specimen was collected – want to link this to the actual instance, using the mCode profile for that

    • for the related lymph node sample we want to point to the sub-procedure (if identified) else use the same procedure rather than linking to the parent

    • collection.procedure as a reference was added in R5, so need to update the Cancer Path to use R5 later

    • We want to add guidance about this into core – Alex Goel  to write up the text (as best practice) and also include the examples for that in a jira for specimen

IHE/SDC eCC ballot reconciliation

• • • Alex Goel ADD LINK
    • 38 Affirmative comments to review, no in-person requests

FHIR-38068 – confirm bi-directional use of .hasMember and .derivedFrom

• • Bi-directional searches are needed in the use case
  • Use case: folks asking for specific observation, that then requires to find the DiagnosticReport(s) that has that observation – this is fairly common, so should we create a special operation for that, so we don’t need to query a gazillion times? – Alex will write this up, as this might solve this problem, because then specific queries are not needed – would make this on the observation – then find the DR and all associated
    • Would this include the orders that go out to reference labs?
      • In theory yes, but in theory we don’t think that the main LIS can track all those results (and they may not be in the format that is needed to include in the forwarded format to the registry)
    • Do we need the order that was placed and the specimen?
    • If we do that, then we could do ELR in FHIR with subscription to disease specific trigger codes
  • Bring this up for the FHIR-I discussion

Wednesday-Q3: Meeting Notes

• ImagingSelection
  • Check how to approach genomic selection and possibly combine into one resource
• MolecularSequence
  • Check out subject - may need to be elsewhere
  • Check out device
• GenomicStudy
  • Check out subject (similar to MolecularSequence)
  • Output is used to then perform analysis that yield DiagnosticReport | Observation
  • Do we need to model Observation.method and DiagnosticReport.study and DiagnosticStudy.SupportingInfo(Procedure) the same to reference the study/procedure that yielded the observation, diagnostic report.  Start in OO Main.  Invite CG and II.
  • Consider changing .analysis.subject 0..1 to .analysis.focus 0..* and adjust choices and include RelatedPerson
  • Is a study a kind of procedure?  Is a study the more analytical/intellectual analysis vs. procedure interventional/invasive (surgery, therapy)?   But what about an interventional study where one must have a cath lab procedure or study?  Need a boundary discussion between CG, Pt Care, and OO so it is clearer when to use when another.  Also note that certain procedures are very granular (e.g., robotic surgeries) or more general.
  • There is discussion to consider analysis to become a separate resource.  Compare .analysis with procedure and observation to help inform whether to keep it, create a new resource, or use either procedure or observation.
• DiagnosticReport
  • SupportingInfo as added.  Need to consider GenomicStudy.  It also has typing available.
  • Some concerns with naming of supporting information, but no clear suggestion
  • Revisiting whether to reference Composition, or whether the direction needs to be reversed.
  • OO will be working on implementation guidance to ensure structures are used as intended.
• Observation
  • Perhaps add valueReference, but concerned with which resources to include as a choice.

Wednesday-Q4: Meeting Notes

• Agenda review
• Update on jiras – anything relating to R5 can get resolutions, but we cannot vote and close them during the ballot cycle, though it can be pre-applied
• documentManifest question
  • is used in STU3 – list is proposed as replacement, but it does not work for the following use case
  • this resource was created to support XDS in FHIR (manifest represents the folder)
  • In NL we have a central index it is in production – referencing classes of data in documentManifest.content with reference to documentReference that is listing the classes of data there – patient provider, type of data – used by middleware to retrieve the data from the gateway, which knows where to find the data and fetches that, where told to use documentManifest by FHIR-I
  • this is supporting an exchange of millions of V3 messages
  • in addition to the above, we already have pdf based document exchange between institutions using documentManifest and DocRef
  • Why not use recordLocator – similar to PIXDPQ?
    • Because the index is larger than just a Master Patient index – it includes meta data around the file content
  • IHE is still using it in ITI - Tom de Jong  to ask John Moehrke 
  • Commonwell Healthline has a FHIR based document exchange
• V2-25391- SET ID in SPM
  • The definition is good here
  • V2 Management should agree to how V2-25342 is being handled
    • Have them come up with a consistent definition we can
• V2-25389 – SET-ID in OBR
  • Technical Correction
  • Capitalize SHALL
  • Will fix in V2.9.1
  • Assign to Ulrike Merrick 
• V2-25388 – Set-ID in OBX
  • Technical Correction
  • Ralf Herzog  is looking into ASTM
  • Suggestion is to drop the reference to ASTM compatibility
  • Since there are 158 mentions of ASTM across the V2.9 standard we want to assign this V2 Management to review if that is something that should be removed across the board or not
  • Triage to assign it to V2 Management
• V2-25376 – Interpretation flag at the OBR level without an OBX
  • For example for a paper result that has an indicator to highlight that the order resulted in an abnormal result (but there is NO discrete result available for use in the EHR-s
    • Why not create an OBX with ED or TX referring to the paper that can then carry the interpretation – in V2 – that might not work in FHIR
  • Still open: What is the meaning of this interpretation, when there are OBX segments?
  • Discuss when Dan is available
• V2-25364 – reference to HITSP in Chapter 1
  • Triage to assign it to V2 Management
• V2-25362 – incorrect ACK code in 7.?? FIND RIGHT SECTION
  • Definitely needs to be fix ACK^33 is wrong – need to check if R32 is the correct trigger event
  • Proposed motion and added grouping for V2 and OO-Block1
• V2-25361 – incorrect ACK Choreography in 7.3.5
  • How to return the ORC Filler order code for the ORU^R31 – we need a NEW message structure if that is supposed the application ACK
  • Similar issue to 7.3.6
  • Bring this to IHE to review POCT IG = LAB-32 - Ulrike Merrick , Ralf Herzog , John D.L. Nolen to bring up and get feedback on the actual requirements.
  • They are using MSA-3 for transmitting the Placer Order number – but that field was deprecated in V2.4, but it is an indication that this message is really an application level acknowledgement
• V2-25352 – LRI NDBS to better describe the DBS result message
  • We should also reach out to Clinical Genomics to find out, if they have any updates
  • Ulrike Merrick to update this and other NDBS related jiras with the example messages collected from the Newborn Screening HIT Committee and also create a proposal text for this one
• V2-25349 – Rename V2-FHIR Mapping IG
  • Hans Buitendijk  will bring up to the V2-FHIR project team
  • We don’t want to change the name, because this project is concerned with the content of the V2 message so that it can be represented in FHIR resources – it is agnostic to the data exchange aspect of this – we need to make that more clear in the introduction

Thursday-Q1: Meeting Notes

• Agenda review
• Overflow topics can go to Friday Q1
• Paper: What is a device? (Link)Todd Cooper 
  • Rebranded the HL7 and IHE device working group to devices lead to writing this
  • Project Gemini (PSS-1980)
    • This has several deliverables some at IHE and some at HL7, was started back in 2019, but we are doing a new proposal to get into the proper workflow
    • Definition of a device may be dependent on jurisdictional law – those are a subclass: regulated device
    • What is the expected outcome in relation to the FHIR IG?
      • Intent is to have a categorization of the devices – so it may add an attribute to the resources and also may support better descriptions around boundaries between resources (devices, deviceDefinition, medication etc)
      • This will also help what work ends up in Devices WG vs OO – communicating devices in Devices, the others in OO (like medical devices = bandaid)
      • POCD also interested in participating in this effort
    • This will produce a white paper – make sure we have specific questions around how does it affect our standards at the beginning of the work to avoid scope creep
    • Timeline: about 1 year
    • PSS – hope OO will be a co-sponsor as well as a few other WGs
  • Discussing use cases around devices
    • What were the set of devices to generate the attributes currently available?
      • Have devices that can communicate; instruments used for diagnostics, wheel-chairs, specimen containers, software – what do we need to know to reference that
  • Gemini project PSS-2120
    • This was never really formalized, so need to establish the governance for Gemini
    • Have been working with Dan and Viet on Accelerator blueprint – may be using that for this project
    • Missing 2 more approval steps before this can go to TSC (one is V2 Management - on their agenda for Thu Q2)
    • http://github.com/IHE/sdpi-fhir  
    • Notes are using confluence (also collects topics of interest / open issues) and Smartsheet for project management in addition to github (IHE) – will probably create a mirrored version on HL7 git
    • Using the github processes for decision tracking
    • IGs that come out of Gemini – where will those be published – this is part of the
    • For the FHIR IG registry there is no requirement to have been created using the FHIR IG publisher – there are actually 2 tools (Michael Faughn ADD LINKS)
    • Surfacing this info from the HL7 confluence pages will be helpful - Todd Cooper to add there
    • Sponsoring WG is HL7 devices and IHE devices group
    • SDPi
      • IHE supplement with 4 profiles
      • PHD FHIR IG is published
      • POCD FHIR IG is being worked on
      • This work will be folded into the Gemini Accelerator – goal here is next 6 months, so we can add our members
      • Device to device communications using IEEE; the FHIR work is for device to enterprise – translating from current V2 connections)
    • Diagram from github.com/IHE/sdip-fhir/wiki/IHE-SDPi-Supplement Todd Cooper to FIX THIS LINK please
    • Plug-and-Trust
    • Will this touch lab automation (Chapter 13 / IHE LDL?)
      • Not in scope
    • Will there be discussion around the workflow, or just resource content definitions?
      • Yes – it will look at the gateway of device communications to other systems in the enterprise
      • Will this replace the POP standard?
        • Possibly
      • The FHIR part of alerting will be done with the alerting IG part (when it needs to get handed off to the central station etc) – have mapping from 60601-8 into the ICM and then will work on replicating that into FHIR environment, so we can utilize the pub/sub paradigm
    • Other Gemini projects will be discussed today Q3 in Watertable
    • Well worked out example should be available by end of October, then we are looking for feedback in November
  • This is using publication tooling that we could use for V2+ publication
• Device
  • FMM level in R5 for publication - FMM3 or FMM4?
    • For FMM3 would need to ensure the Quality guidelines are working, we already have all the others
    • Since device is being used in production FMM4 may be a good level to ensure we get implementer consultation?
      • We may not want to lock ourselves down quite yet
      • We really don’t have specific use cases or documentation about testing capability
    • Decision: aim for FMM3
• DeviceDefinition
  • FMM level in R5 for publication - FMM2?
  • Definition resources are specifically being used in CQI use cases, devices do not use it
  • We still need to work on ensuring consistency around the use of attributes
  • Decision: leave at FMM1
• Device.specialization
  • This is confusing name compared to its definition
  • We kept it for backwards compatibility
  • Looking at the entries in the type code system that seem to have the type of device for which a standard exists, rather than listing the actual standards this same valueset is used in device.type
  • Need better definition to how to populate the version element
  • Maybe add additional attributes or rename to “conformsTo”
  • We would like to have this be a ballot comment for R5 Elliot Silver 
  • In device world standards are identified with OIDs (which would include then the versioning) – so may want to have a different datatype = identifier
• New resource proposal to do deviceAssignment (take the patient out, but able to associate device with other resources or across multiple s
  • How does that fit in with deviceUse vs deviceDispense
  • Related issue is how to keep history of device settings done during procedure – need to have the relationship between device and procedure
  • We need to also consider how to use device when using it for specimen
  • Make this a ballot comment Elliot Silver 
  • IHE has v2 based profile Todd Cooper  to add the name

Thursday-Q2: Meeting Notes

• Planning
• FHIR-38635 - See vote and approval.

  • Change to be made in R5

  • Persuasive with Modification Motion by Rob Hausam/John Moehrke 18-0-0

  • Assigned to John Moehrke

• Workflow Update
  • Guidance document (not IG) on how to use ServiceRequest and Task more consistently as currently there is variations in how different IGs are approaching this.
  • II is working on an IG on how FHIR workflow approach impacts DICOM.  Should be added to the list.
  • Also need to look at service model.
  • Need to resolve how to publish this guidance.  Special page?  Project Team to review with Publishing, FHIR-I and OO.
• Task - Aim for FMM3 as 4 seems a stretch.
• Device Used Parameters
• DiagnosticReport/Composition

  • Need to coordinate between OO, PC and DEV for how to handle the device settings for multiple scenarios.  Current proposal is to have in included in Procedure

  • Need to capture if the device is “doing” the procedure; or the device is “used” during a procedure;

  • There are device-level and patient-level information that needs to be considered

  • Diagnostic Report/Composition

    • Discussed multiple ways to handle the sequence/order (See diagram developed)
    • Bundle of composition
    • Diagnostic report has the ability bundle natively
    • Diagnostic Report as a type of Composition (i.e., a profile)

    
    

  • Next steps to address this issue: Follow-up conversation with XE Health and Belgium

Thursday-Q3: Meeting Notes

• Agenda review
• Review of Transport resource
  • intent need to add code to indicate record – since the element is 1..1 and the vocab does not include something to record the event
    • Should we remove this element, if the reason to have this is for documentation only
    • Do we need a pre-defined set of movement (that’s when we need to have this element) or should we have the transport resource in the case of orchestration be the output of the task and then we could remove this element
  • partOf
    • Why is “contract” in the value set (we could see it if it was used in something like ‘justifiedBy’) – maybe left over from task?
    • Should we add ‘task’ to this list?
    • It could also reference planDefinition
  • Do we want this to be a transport event or the intent
    • Order to move the patient is using ServiceRequest
  • We need to update the wording in the structure to be clear this is an event
  • PA seems this would work with ServiceRequest and transport (and maybe task, if needed) – for history of the transport, PA created encounterHistory (we planed to remove encounter.history for R5 – it is in the current build = make ballot comment
    • Encounter #1:
      • Patient in bed#1 – move to bed#2
      • Patient is being transported (using transport to document the event)
      • Afterwards document the administrative event = use of encounterHistory
    • For lab automation record the location of the specimen from prep to instrument etc – this has many different transports; could be one pre-defined longer string of transport steps or individual transports
      • How will each of the steps being tracked? Using partOf may not be enough to surface the dependency of certain transport parts
      • We should update the name of ‘history’ to ‘preceding’ to match the definition
    • Should we add a category to the transport – currently we only have the reference to the instance, but not a category - type
    • Should we create a pattern for tracking resource history for encounterHistory and device setting tracking in a procedure – do we also need to track the assignment of the person that have used a device (could that be done by deviceDispense – this will cover when we have assign it to different people, but it does not cover non-use in between or when this is being put back on the shelf
      • Currently device mandates the patient as an attribute (for implanatable devices) – should we create a new resource to describe the association between person and a device – Elliot will create a jira for that
      • Cooper plans on submitting a tracker to allow association to practitioner also
    • Describe overlap with supplyDelivery
      • supplyDelivery can describe shipping it out or receiving it, while transport is about the actual movement in between?
        • Have we defined supplyDelivery as the outgoing resource
        • Could supply shipmen be a profile of the transport resource?
• R5 PA Updates
  • Encounter changed referenced datatypes
    • ExtendedContactDetail instead of ContactDetail
    • Availability is leveraged in several locations
      • removed the backbones for several performer locations
      • this datatype is also used for address of patient
      • Best time to call = Gravity modeled this as observation - should we make a comment to update that? - WHO???
      • Can this also be used for medication and inventory?
        • in extensions
      • VirtualServiceDetail
        • Storing telehealth details for participating people in telehealth visits
      • MonetaryComponent
        • Finance structures (invoices, pricing details (base charge, surcharge, discount) – describes each of these components (so you don; have to create specific attributes for each one
          • Definition for MonetaryComponent is incorrect (copy/paste from availability)
  • Created encounterHistory resource Cooper Thompson  - please ADD LINK, I cannot find in current build
• FHIR-36650
  • PV1 mapping V2-FHIR
    • For temporary locations should this be a v2 extension (this is NOT specific to V2, because it is use case specific – so make it a standard extension; would this maybe go into encounterHistory?
    • What does it mean when the patient is temporarily at this location?
    • Would transport history show this?
    • Or update the encounterHistory with the different locations
    • We consider encounter.location to be the assigned location and this standard extension can then describe the temporary location
• FHIR-32997
  • This needs to be applied – is a UTG proposal
  • this proposal needs to be reviewed by v2-FHIR project (Hans Buitendijk, Craig Newman)
• Procedure.bodySite
  • Can we make this a codeableReference to bodyStructure – this should have been on docket for PC, not PA
• Can we add supply topics into the catalog call timeslot?
  • Need to discuss with Francois
• We will keep the same time for joint meeting at Jan 2023 WGM

Thursday-Q4: Meeting Notes

• DMPAddendum Review
  • We have updated in Jan18, 2022, so not sure this needs to be done again already
  • We kept the track changes since we made some changes outside the colored highlights
• Jira review
  • V2-25376
    • For V2:
      • How would you handle the added interpretation in OBR when there are OBX(es) with interpretations available - is it a summary or only used, if no OBX?
        • probably would role up - if any of the interpretations is abnormal of some form, then the code rolls up = would need to provide rules on how to map from the OBX-8 or is this more of a flag for physician review?
        • Epic has concept of "unsuccessful event" - exam was perfromed, but it did not be satisfactory for the requirement - example here is a colonoscopy that was done, but cannot be counted against the prevenative screening requirement for example - so maybe we need a clinical assertion flag - maybe that could be combined into this new field? if we do that could we also use that in FHIR - Daniel Rutz to create a new Jira and link to this one, so that we can discuss together
      • you have a result, even though if it just a paper or scan of a paper - would create an OBX with datatype either ED or 
    • For FHIR:
      • Create a ServiceRequest and a DiagnosticReport with a pointer to the image of the paper scan in .presentedForm, so there is no creation of an observation for this report
  • Update on the DiagnosticReport changes around result
    • What do we really need: hard requirements what is permissible / not permissable for CLIA requirement acceptance from Freida Hall and Kathy Walsh  (with some good examples from the differnt domains in the lab) - so that the presentation in the EMR is matching what is in the report on the lab side to help us decide what we need for grouping / ordering. Also need ot understand if the report signature is par to f the report, or is the addition of the signature added AFTER review of the report (stamped later) even though the precedent in V2 is to just reference it to the Medical director
    • presentedForm: the laboratories canonical representation needs to be presented in the EMR (use a pointer to the composition into presentedForm (rather than pdf - or in addition) to create the "report of record"
    • Having DiagnosticReport and composition exist in parallel should not be an issue, we may need to create an invariant
    • What type of signature do we need to have - electronic or digital (assume we will have to have digital for Europeanrules sooner or later
    • In order to ensure the full report is always signed and available - maybe put this into the structural version of the .presentedForm?
      • this is supporting the 3 actions rule for this data as described in the EHR-s Functional Model IG for LRI
      • can we live with the situation where we have a data in the structured data that is not in the presented.Form, and vice versa?
      • this might make presentedForm the source of truth
    • We can have more than one presentedForm, how do we make clear which of those is the source of truth is the one of these that is signed
    • At the moment we only support attachment as datatype
    • Do we need a backbone element?
      • indicating which one is the "Report of Record" or do we need a presentedForm.type
      • also do we need a different element for referencing the componsition (not sure that we want to do that - reason to do that would be we could sign this in a special place and can then work with the other elements) - but presentedForm is really meant ONLY to be visually consumed?
      • who is the signer of presentedForm - in the lab case it is the producer, but that is not clearly defined in the resource attribute = we also should make sure that the presentedForm is clearly identified that this should be a SINGLE report, not indiviudal pages of a report
    • John Moehrke how can we ensure an attachment is digitally signed - is there a reference you can share?
    • For ordering: in the element definition for any cardinality n ..*, which is defined as an array, you can indicate that order matters
      • it has the attribute of OrderMeaning (which is a string)
      • if the element is not populated, then there is no rule around ordering;
      • if populated, then the string describes what the order means
        • example would be preferred telephone numbers
    • What makes something a diagnosticReport over a SurgicalNote, which is a profile on composition?
      • we could make DIagnosticReport a profile on composition
    • We would need to decide if we want a single solution for simple and "regular" and very complex reports vs. having differnt solutions for each of the different places 
      • user suggests the profile on composition

Friday-Q1: Meeting Notes

Devices

• Review Mappings
  • will need to revisit in light of the device resource changes - there are a few changes on the device attributes we are still making
  • goal here is to ensure device has the attributes needed for PCD and POCD
  • should we consider creating specific profiles for these type of devices = that is in the respective IGs
  • goal of mapping is to map to IEEE verbiage
  • PHD - Brian Reinhold
  • POCD - John Rhoads
  • Need to review others as well.
  • Any data elements that need attention in the standard should get ballot submissions, so needs to be done before Oct 14.
• Examples/Stable Elements
  • Need to review, could be included in the mapping review maybe?
  • Need to look at examples to ensure folks have what they need for connectathons
  • Ensure we have examples for testing ALL elements for the different devices (PHD, POCD, UDI exchange ID) – focus on changes we have made in last cycle
  • Assign owner on Wed Dev call Marti Velezis  and John Rhoads 
  • Prefer to have any suggested updates done as part of Ballot submissions.
  • Include a Catalog boundary line to clarify purpose vs. Catalog and point to Catalog for more information.
• Look at use cases we need for associations to the device
  • Besides single patient for implantable device as we do now

DeviceDefinition

• Scope/Boundary
  • Clean up language so it does not duplicate Device language that already clarifies that.  Hans Buitendijk to prep proposed disposition FHIR-38711 
  • we make sure folks know about the existence of this resource and all the other resources that have definitional resources (catalog); some resources have this separately while others have this included, but we have a way to clearly distinguish between the two uses – make this statement in catalog to explain this
  • Include a Catalog boundary line to clarify purpose vs. Catalog and point to Catalog for more information - we can do for OO owned resources
  • Need to reach out to other WGs that have resources that can be used in catalog Jose Costa-Teixeira 
• Mappings
  • Marti and Francois are updating the mappings to EUDAMED and GUDID and as needed record JIRAs to DevDef
    • If folks have other use cases, let Marti and Francois know and help them out

Device and DeviceDefinition Other Text

• There is other text where the difference between the context of device and device definition needs to come through clearly.  We need to review this across all text.
• Need to address variations in how we represent concepts across device and deviceDefinition – look for changes and examine if changes are needed in deviceDefinition or explain why the difference is there – while keeping the names of the attributes the same to enable the “mappings” between the two

Use Case Reviews

• We need to create use cases that cross resources that further help clarify use and boundaries.
• Jose is going to create some example drafts and Lloyd is going to find a place to put it.

Device Association Discussion

• There is a need to associate device to different subjects over time / other types of resources
• Need to change the attribute label "humanSubject" to "subject"
• With PC had discussion around documenting specific settings of a device used in during a procedure
  • Where to do that – in procedure, in device or a new resource?
    • On device the settings may be specific for JUST the patient in that specific procedure (and may even change during the procedure over time) – or are these captured as observations in procedure?
    • Or keep changed to calibration ONLY in device, and the other kind of changes keep outside of device to document the use of the device over time
  • How do you associate more than one patient with the device, so you would leak PHI to all the different patients – so we should remove patient
    • Discussed using DeviceDispense and DeviceUsage both cover some of this, but how to you create a log of patients that have used a specific device (and similar we may need procedure logs and inventory logs) – this may be a more generic discussion first
    • Do we really need to track it from the device backwards, or is the forward association from where / who used the device is good enough?
    • The question may be where are devices with this serial number(s) been?
      • Where is this list: Dispense / Undispense / Transport
      • Do we capture the event of the change vs the time between the changes
    • IHE has Supplement PCIM has this as a V2 profile – we should look at that https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_Suppl_PCIM.pdf
• need to review any change for backwards compatibility - maybe keep the assoication in the device resource ONLY for implantables and make that 0..1 and then create a variant to enforce that Jose Costa-Teixeira  to create example scenarios Elliot Silver to add the JIRA here
• Lloyd likes moving the association out, but may need more disucssions:
  • scope for just device - document the association that change over time that need tracking beyond history - patient, what else?
    • some of these may influence access controls
  • once we have the list look for other things that we may need to do this to as well and then reach out the their owning WG
  • we want something stable for R6 for sure, but if=delaly pull this out by R5, so bring this to FHIR-I as well

  • zulip chat about associations on patient for preferred pharmacy (only need current really, so does not map to the device association use case)

  • NEED HELP WITH THIS BULLET: defining characteristic is ??? 
    • use case: who has this device been used on (e.g. endoscopes in infectious situations, exposure of physicians)
  • Existence of DeviceDispense implies a DeviceAssociation
  • why is AuditEvent not good enough?
    • this is often only accessible to security (it tracks the information about the item), but that also applies to the provenance resource
    • these also don't move from system to system
    • we are not neccessarily looking for event log, but rather a timeframe
    • you also don't want the whole history in 1 resource
  • could we use https://build.fhir.org/episodeofcare.html for that?
    • that may work for patient, but how do we do that for other things
  • a device may be assigned to a patient = DeviceDispense, which is the start of the association period, but we may only know about the asosciation period, but not have information about the dispense
• More generic aspect of tracking what devices (or other resources) are associated with - start just with patient, but may need to also to look at practitioner, ward etc - and how to create logs for this as well - getting into inventory handling a bit
• Does this include who operated the device?
  • may need the log for a particular time range (during a procedure) - probably need complex search parameters
  • DeviceUseage is a patient reported element
  • there is also a clinician assertion (if device was assigned during encounter
  • there is the system assertion of the association to the device (for example: label was printed with patient name)
• Need to be clear if we want to track the giving out/association to or the having of
  • we need to ensure we have good documentation what this new resource is expected to be used for (making lists vs including in operational workflow, where we have overlap with existing resources)
  • we can draw an analogy from medication world (where we use the list of medications, when checking for contra-indications, not dispense or administration events
• Do we need the distinction between single use (expected anyways) devices vs reusable devices?
• Do we need to track associations between 2 devices / products (centrifuge vs blood in container)?
  • need to review against genomicStudy, where the consecutive use is important to understand the results
  • tracking AI algorithm as devices

How do we model software in a device resource?

• There is a software as a medical device (dealing with this as component of the device) vs dealing in FHIR resource
• There is also software embedded in devices (software releases - are those individual devices (when installed on a specific machine) or deviceDefinitions) - need to set up a call between devices, OO and mobile health Marti Velezis and John Rhoads to plan this out
• when we are dealing with AI, include II WG, as they are most advanced in that discussion
  • how do you track the changes in AI algorithms

Friday-Q2: Meeting Notes

Reviewing the HCD Dashboard

• FHIR-32271 - Getting issue details... STATUS  = DeviceDefinition – modeling relationships between devices
  • You need to traverse this in both directions, but should you have 2 elements that are doing it
  • In the definitional resources it seems more practical to have .hasPart while in the device definition for reporting purposes it makes more sense to report from the part that did the measurement
  • You can look for things that don’t have .parent is the top level device, which is most likely what you need
  • Need to get input from Marti and Hans – we should definitely document the rationale to have both and update the and create an invariant when to use what
  • @Elliot to find his own tracker on this topic
• FHIR-37812 - Getting issue details... STATUS
  
  • Device is not always associated with a patient, but that should not limit the parameter
  • We could not locate the URL referenced
    • We looked at the following search parameters:
      • ADD LINK to observation, device and encounter
      • All include the name of the resource from which the linkage is made
      • We also looked for the “find all resources for this patient
  • Since we did not find the "clinical-patient" search parameter, asked submitter to clarify

RIKI STEPS OUT - so anyone who has notes PLEASE ADD

• For recall
  • you get lot number ranges, so still at definitional level
  • Today the production identifiers on deviceDefintiontypes are boolean and which of these is it labeled with that would require a change in datatype – can do CHOICE but then need to define what
    • In EU having a lot number on the label, then it is not controlled by it – but you still need to indicate the numbers
    • In US you would just need to indicate that it is on the label, which means it is controlled at that level
    • If a range of production identifiers is not included, then it is ALL
  • So need NEW attribute for that
  • With use of .hasPart only the smallest part would be identifiable – how do you indicate the top level device = identify the iPhone rather than all the components
  • Need to also be able to deal with system of systems
  • Does .hasPart.count need to be a range?
    • Example blood pressure cuff sizes – would refer to each type as instance of the attribute and then count comes in, so no
  • Sounds like we don’t need parent – Elliot to put explanation into proposed disposition