Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Monday

Q1 and Q2 = Plenary

Q3

Chair: Hans Buitendijk

Scribe: Riki Merrick

Review Agenda review for the week

  • Rooms have been changing quite a bit – so check the agenda
  • FOR V2+ (Tuesday) and V2 to FHIR mapping (Thursday tooling) use M102 for Q0
  • Friday AM overflow quarters possible, if needed – will check on Thursday
  • Using OO regular Free Conference call line when we need it

Attendance log https://confluence.hl7.org/display/OO/OO+WGM+201909+-+Attendance+Log?src=spaceshortcut  – please sign yourself in

Agenda for today

  • Report on breast cancer ballot result will do today (time permitting, else Tuesday Q3)
  • Follow up on Nutrition intake
  • Blood Administration
  • Se Referral PSS Co-Sponsorship
  • Self-Measured BP - need dial in for Corey

Additions:

  • Device Request / Parameter
  • Device Use Statement
  • ServiceRequest Order Detail
  • ServiceRequest order detail (CIMI/CQI)
  • DeviceRequest reason code and parameter use statement

Referral PSS:

  • Seth Blumenthal from AMA
    • Integrated Health Model initiative at AMA – now using HL7 for DAM
    • Get slides
    • ONC chairs of Interoperability taskforce suggested common data elements for patient referrals
    • Goal of this is the payload / content
    • Gravity is HL7 accelerator project for social determinants for health
    • SIREN is UCD research community project
    • UT is implementing social determinants for health
      • Unite us system for non-medical referrals
    • Which WG should have this project?
      • Patient Care as primary sponsor for content
      • OO as cosponsor (both content and process/transport)
      • Transport
        • Process would be PH WG – John Loonsk and AMS – have balloted referral FHIR IG
        • Non-FHIR in IHE using direct transport = 360x work
      • VA did a lot of work on knowledge artifacts for questionnaire and order sets will be on HRQ CDA connects
      • Is this like a patient summary? – specific to a use case would be better, so that we have the participants for connectathons
      • PSS for parent with multiple workstreams
        • Child PSS would be for the specific use cases
        • Publishing facilitator should know the HL7 process
        • Will have to collaborate with CIMI /CDA and CQI, so that the same data elements
      • Come back for vote of at least Co-sponsor
    • Self-measured Blood pressure PSS
      • Lorraine drafted a PSS from the prior presentation
      • Slides from Monique van Berkum, AMA
      • Already developed IGs based on FHIR STU3
      • Model was created outside of FHIR over the last 3 years
      • OO is already the primary sponsor
      • Goal is to take IHMI knowledge and align it with FHIR
      • Governance level question for the exchanged data = can we test if our definition is consistent across implementations globally? Idea is the common standard representation (from bottom up that needs to be coordinated for the different
      • CIMI has a vital signs PSS extending US core – working using ONLY LOINC – need to compare and come up with just 1 FHIR profile for bloodpressure – do not limit to US realm – should we sync that into one project
        • In experimental model used procedure in test = measurement of blood pressure instead of SCT observable or LOINC) – also use this same code in method / and as a goal
      • People are not implementing FHIR STU3 = should be STU4 instead
      • CIMI already has a PSS – which PC is sponsoring – OO owns the vital signs profile, so we need to work with PC and need to add OO – this has not gone through SD and TSC
        • CIMI will show their model in Tues Q3
        • Model is built on FHIR STU4
        • AMA is including more processes of how this data is used in clinical care, while CIMI has the model of a broader data (Vital signs profile includes self-measured blood-pressure)
        • Already presented to PC, OO and Mobile Health
          • Need to add CIMI as co-sponsor
        • Next step:
          • Define AMA objectives and compare to scope of existing PC PSS and decide which part is under the existing PSS for the overlap = Lorraine, Monique and CIMI
        • Breastcancer ballot
          • Lots of comments
          • Got a lot of ideas about what patterns and resources we should be using
          • So will result in significant changes for Jan2020 cycle
          • Connectathon May2020
          • Will add more clin content and terminology
          • Numerous choices for breast cancer report:
            • DiagnosticReport
              • Not enough sections for the current expected design
            • Composition
            • DocumentRef
              • Argonaut is working on first STORE operation for this resource, so we can get implementation in community
            • For the device topics find other quarters
            • Blood Administration
              • What resource to use for that? = no known resource yet
              • We have Tuesday Q1 for healthcareProduct process patterns
              • Can we have a resource for that for R5 – need a group of folks to work on that
                • First have to define what a biologicallyDerivedProduct is covering that – we don’t have a resource to describe the administration of the blood product
                • Clinical Quality measure for blood product administration
              • Looking for volunteers to draft something
            • Keep the same joint for Syndey

Adjourned at 3:03 PM

Q4 = Joint with FHIR-I - see there for minutes https://confluence.hl7.org/pages/viewpage.action?pageId=66913703#FHIRInfrastructureMinutesWGM201909-MondayQ4


Tuesday

Q1

Chair:

Scribe:


DeviceUseStatement

  • Or Procedure
  • Or Observation
  • <resource>UseStatement is meant more from a consumer/patient, could be the clinician, but then not the prescriber/requester/administer.
  • For CQI it is important that it is "applied/administered", as reported by clinician.  Sounds like more the Procedure (when implanted/attached).  Still tbd for DME.

DeviceMetric

  • Or Observation
  • Reflects the state of the device.  Not to be mixed with observation which is the output of the device for a particular subject.
  • Observation.device(Device) is clear.
  • Observation.device(DeviceMetric) references the DeviceMetric that yielded the observation, which in turn points to the Device.
  • If you want to know the state of the Device (collection of all DeviceMetrics) at the time of the observation then that has to be resolved elsewhere.
  • Will create clarifying language in both DeviceMetric and Observation on what aspect of DeviceMetric is used by Observation.

gForges (Devices)

Q2

Chair:

Scribe:


  • Observation.valueAttachment?
    • Options
      • Observation.derivedFrom => Use case would not have Observation.value
      • Observation.valueAttachment => was in DSTU 2 and it is an actual result value.
      • DiagnosticReport.presentedFrom => Inconsistent placement of an observation.
      • Observation.extension-valueAttachment =>
    • Motion to propose in Q4:
      • Define Observation.extension-valueAttachment so it can be used with FHIR R4.
        • Requires determining where to post it. 
      • Include Observation.valueAttachment into FHIR R5 build as an STU item.
      • Document clearly when to use Observation.valueAttachment vs. Observation.derivedFrom vs. DiagnosticReport.presentedForm in
        • Observation introduction
        • Element definitions
      • Kathy Pickering, John Moehrke
        • Against: 0
        • Abstain: 1
        • In Favor: 10
  • Nutrition Connectahon Update
    • Unfortunately partners did not show, but will be in Sydney
    • Worked primarily on documentation and examples.


Q3

Chair:  Robert Hausam

Scribe:  David Burgess

Q4

Chair:  

Scribe:  


Wednesday

Q1

Chair:  

Scribe:  

  • AMA - Referral PSS
    • CDS, CQI, FHIR-I, Vocab, Pt Care, Public Health
    • Overall good interest. 
    • Lot of work has already done (360X, eReferral), but mostly focused on mechanism, not content.
    • Would like to proceed.  Perhaps start with whitepaper to identify needs, gaps, etc. and then recruit.  Perhaps start with DAM.
    • Suggestions to start with whitepaper.
  • Device.status

Active - Remove "Note: For *implanted devices* this means that the device is implanted in the patient."

Inactive - Remove "Note: For *implanted devices* this means that the device has been removed from the patient."

OR

  • [operational]Status 0..* with active, inactive, implanted, explanted, dissolved/absorbed

OR

  • [operational]Status 0..* with active, inactive.
  • implantStatus 0..1 with implanted, explanted, dissolved/absorbed

OR

  • [operational]Status 0..1 with active, inactive.
  • association 0..1
    • association.patient (reference) 1..1
    • assocaition.level/status 0..1 with implanted, explanted, dissolved/absorbed
  • statusReason value set: malfunction, partially function


Q2

Chair: Lorraine Constable

Scribe: Riki Merrick / Lorraine Constable

  • Healthcare Product Recap
  • Cancer specifications for Genetics (M-codes, v2 IG, and FHIR)


  • Clinical Genomics
    • close to publishing Genomics reporting Implementation guide
    •  will replace current extensions in 
    • R5 deprecations 
    • technical correction on examples
    • questions about searching and computational observations


  • II
    • Specifics around DocumentReference and Media for tomorrow
    • co-sponsor updates


  • BR&R


Q3

Chair:  

Scribe:  

Q4

Chair:  

Scribe:  


  • v2-to-FHIR


Thursday

Q1

Chair:  Hans Buitendijk / Riki Merrick

Scribe:  Hans Buitendijk / Riki Merrick / Lorraine Constable

Agenda

  • Catalog/LIVD
  • DeviceStatus 0 discussion to start around 9:45 AM EDT
  • LIVD gForge (ballot reconciliation, time permitting)

Catalog

  • Francois shares his slides 
  • And rationale for the design of catalogs: https://docs.google.com/document/d/1JzDoIZlaPZTvMCg887DnPn0JLR4VJjqQ70Gru5_nBvQ/edit?usp=gmail
  • Need to start adding II use cases into catalog
  • For LIVD we have entered a gForge tracker, to add in the catalogEntry, if we will do this for consistency sake, or if we don't need it in that instance – described last slide of the presentation
  • Cqm datatype is owned by SD
    • Why is this only a single date//time = it is because that is the starting date
  • Why use composition and not list?
    • This presents the catalog as a whole – using composition to provide the structure and the metadata needed = comparatively to the "book" – this had lots of discussion with FHIR-I and SD
    • List does not have all the elements we needed
    • DaVinci used list for formulary IG
    • we have tracker item to describe the boundaries between composition list and documentReference
  • SD has a profile on composition for clinical documents, where the record target is 1:1
  • We do have a LOINC for LIVD – ADD?
  • Rx agreed to remove catalogEntryType attribute, since we also have type at the higher level – and we have referencedItem
  • referencedItem will allow a tagging mechanism – we may need to replace substance with substanceDefintion
  • RelatedEntry is for version tracking – the relationship between included catalogEntries is done in the activityDefintion as well as the structure of the composition
    • we have relationships in 2 places
    • we may need to revisit
  • What additional information would we use in the catalogEntry in the LIVD?
    • when we do the multi-manufacturer catalog, this may be helpful
  • Using composition with a lot of references seems like bad practice – in current FHIR servers will be hard to do
  • Create a catalog header and keep most of the hierarchy in
  • For catalog service structure may create rules of using import and export features when exchanging
  • For exchange could use the bundle to exchange the entire catalog
  • Storing this as 1 blob and do operations in this, then that is the problem with this approach
  • This structure does not impose a storage paradigm and how folks are going to use this resource
  • In composition we are referencing out to catalogEntry
  • Suggestion is to reference back from catalogEntry to catalog header
    • this would need to be raised with SD
    • if incremental updates are needed may need to use the reverse references vs the forward references currently supported
  • LIVD group should review catalogEntry attributes to figure out if we are going to use this
  • Also need to update boundary discussion in the resource proposals – see the rationale document for fodder


Device Status

  • Device Status Options
    • Option 1a:
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..1  CodeableConcept on|off|standy|etc.
      • Add Device.operationalStatusReason 0..*
      • Add Device.associationStatus 0..1 CodeableConcept implanted|explanted|attached|etc.
      • Add Device.associationStatusReason 0..*
      • :
      • Add Device.etcStatus 0..1 CodeableConcept whatever
      • Add Device.etcStatusReason 0..*
    • Option 1b
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..1  Backbone Element
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
      • Add Device.associationStatus 0..1 BackboneElement
        • value CodeableConcept implanted|explanted|attached|etc.
        • reason 0..* CodeableConcept
      • :
      • Add Device.etcStatus 0..1 CodeableConcept whatever
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
    • Option 1c
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..1  Backbone Element
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
      • Add Device.associationStatus 0..1 Backbone Element 
        • value CodeableConcept implanted|explanted|attached|etc.
        • reason 0..* CodeableConcept
      • Add Device.otherStatus 0..* Backbone Element whatever
        • value CodeableConcept on|off|standy|etc.
        • reason 0..* CodeableConcept
      • Like the use of BackboneElement
      • like use of associationStatus rather than just implantableStatus
      • tracking real world statuses
      • not easily extensible without effort
      • beneficial to be explicit about the first 2 attributes
      • this is also in line with FHIR-I, as they dislike the apporach of using name - value pairs
      • how will otherStatus be defined = using the valueSet content to describe the context
    • Option 2
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.operationalStatus 0..* Backbone Element
        • value 1..1 CodeableConcept
          • on|off|standy|etc.
          • implanted|explanted|attached|etc.
        • reason 0..* CodeableConcept
    • Option 3
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Add Device.?name?Status 0..*
        • value 1..1 CodeableConcept
          • on|off|standy|etc.
          • implanted|explanted|attached|etc.
        • type 1..1 Coding operational|association|etc.
        • reason 0..* CodeableConcept
    • Option 4
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Update Device.property.type value set (needs to be fixed regardless) for operational and association 
        • seems to work for operational, but not for association that well.
      • Update Device.property.valueCode value set 
        • on|off|standy|etc.
        • implanted|explanted|attached|etc.
      • Add Device.property.reason 0..*
        • does not seem to fit.
      • Implanted is not the status of the device / not a property of it
    • Option 5
      • Remove Device.status
      • Remove Device.statusReason
      • Add Device.active 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Use DeviceMetric where DeviceMetric.parent links to the Device
      • Update DeviceMetric.type value set (needs to be fixed regardless) for operational and association
      • Change DeviceMetric.operationalStatus to Codeable Concept
        • on|off|standy|etc.
        • implanted|explanted|attached|etc.
      • Several people don;t like tis option of using a different resource for describing device statuses
    • Regardless
      • Add DeviceMetric.active
      • Drop entered-in-error from DeviceMetric.operationalStatus
    • Motion to accept option 1c except the first 3 bullets - confer with FHIR-I about the appropriate use of the participant pattern for device.status
      • Lorraine, Rob further discussion: Rob and Bob and Marti prefer the option 1b, unless we have a specific use case for the otherStatus;
      • change motion to use option 1b, excluding the first 3 bullets
      • against: 0, abstain: 0, in favor: 13

Q2

Chair:  Lorraine Constable / Hans Buitendijk

Scribe:  Hans Buitendijk / Riki Merrick

  • Value Attachment
    • Motion to:
      • Define Observation.extension-valueAttachment so it can be used with FHIR R4.
        • Requires determining where to post it. 
      • Include Observation.valueAttachment into FHIR R5 build as an STU item.
      • Document clearly when to use Observation.valueAttachment vs. Observation.derivedFrom vs. DiagnosticReport.presentedForm in
        • Observation introduction
        • Element definitions
      • Eric Haas, Lorraine Constable
        • Discussion
          • Needs 1..* gForges. GF#24693, GF#24695  ( need to complete)
          • May need more absentReason values for Observation.value[x] in order to deal with pdf that may or may not have structured data available 
        • Against: 0; Abstain: 0; In Favor: 15
  • Device
    • Reviewed the options in Q1 above
      • Participant pattern has participant.active

      • Device resource has statuses and in mapping to the pattern needs to show which of the statuses applies to the participant.active Boolean

        • would need to update the definition for this in the pattern = pattern describes the kind of thing the resources should support

      • Still have the record status in device resource – rename device.status to include specifically recordStatus

      • Need to still clarify the valuset for the record status

      • Difficult time explaining associationStatus use as a property – maybe improve definition of property to make it more clear

      • Property should describe the device itself – operationalStatus may work in property

    • Motion to update the definitions and value sets of Device.status and Device.statusReason to make it clear they focus on the status of the record of the Device.
      • Hans Buitendijk, Riki Merrick
      • Against: 0; Abstain: 2; In Favor: 13
      • created GF#24696] ( need to complete )
  • FHIR Planning
    • New target of first FHIR R5 ballot for 2020 May, resulting in R5 pub date Jan 2021.  Is that o.k.?
      • Intent to focus on FHIR survey to find out when a next release would be be adopted with current version of FHIR.
    • Is there value in interim milestone for resources that have enough change to be made available?
      • Approach would be SOMETHING LIKE (not clear) to take R4, fork, make the select updates, ballot, and publish an STU.
      • If it happens, we would consider:
        • Substance because of BR&R, maybe researchSubject – boundaries between substance and substanceDefinition
        • Specimen
        • Catalog
        • anything in scope of PatientSummary would be in the scope for interim updates
        • Healthcare Product scope/boundary updates.
      • But O&O would not be pushing for this.  No urgency.
    • Need to commitment in Sydney to R5 Normative targets.
      • Device
      • DiagnosticReport
      • DocumentReference?
      • Specimen?
    • Discussion around the potential need to split Device, e.g., hardware vs. software? Implantables/etc. vs. tubes vs. diagnostic equipment/analyzers?  Method/algorithm vs. something "tangible".
    • How to deal with administrative observations like number of beds in the hospital = use measure for this – needs to be written up as
    • What changes can be done to normative?  Still needs to be backward compatible.
      • device = reference to device and deviceMetric
        • This is choice of very different things
        • Could we split that into 2 different elements/references? = targets of references can change even in normative resources, if we can demonstrate that no one is using the reference to be removed
        • Requires a lot of community research and clear labeling in
        • Extension for protocol for GC
          • Need to reference a protocol
          • Describe, when for an instance the protocol was not followed
          • Document the reason for the deviation
    • Use: http://clinfhir.com/igAnalysis.html to find use of extensions beyond what is in the HL7 registry.  No guarantee they are actually in use or were just considered.
      • Looking at extension reviews.
      • Implementation guide based not standard extension
      • In V2-FHIR mapping we are looking for existing extensions we can reuse
      • How to balance re-use of extensions in FHIR?
      • Naming conventions of profiles need to be better clarified – for re-usability of profiles and extensions = question for FMG
        • Grahame is working on improving extension review as part of found in pre-ballot quality review steps
  • DocumentReference/etc.
    • OO needs to work the queue – John Moehrke is owner of this resource
    • Deleted media – attributes were added to valueAttachment and scope of documentReference was updated
      • Were all references to media replaced with documentResource? – check with John on that
    • What else is documentReference expanded to – nothing intentionally
    • Topics for further discussion:
      • What happens to documentManifest now that documentReference is OO?
      • Name change to objectReference, since it is larger scope now than just documents
      • Use of DocRef for XDS by IHE concern.
        • this requires discussion with John Moehrke
        • IHE workflow approach – need to bring to workflow group / task = bring up under projects
      • Media has been replaced, we think.
  • There is also overlap between workflow and healthcareProduct discussion
    • Chapter 4, 7, 13 and 17 all cover workflow
    • Task ownership – OO or FHIR-I
    • Testing task using Lab Order Conceptual model and how that translates to FHIR
    • Invite FHIR-I workflow project to OO quarter how these workflow components apply to the resources OO owns

Q3

Chair:  Hans Buitendijk

Scribe:  Riki Merrick

  • Link to the master spreadsheet will be on top of V2-FHIR project page – Hans to do
  • When to ask for extension from a WG on a resource they own
    • After ballot? – not really
    • At start of mapping – too early
    • When community review is completed and feel comfortable to send for ballot review – just right!
    • We expect the WG to provide feedback on what extension is appropriate
  • How to prevent duplication of extensions?
    • Need to start to apply governance
    • Will request WGs to review existing extensions next year
    • Setting up a registry for extensions (should be functional soon) and suggestion is to look there first
    • Have tools to find out where extensions exists outside of HL7 core extensions (IG based) ADD LINK HERE!
    • Consider label of "not HL7 approved" that will generate
    • HL7 has not veto power over extension in namespaces owned outside HL7
  • Overview of the process and format
    • Draft mapping
    • send out for community review
    • apply comments from community
    • put in "ready for ballot bucket"
    • use narrative to document that the element should not be mapped, because not needed vs is not mapped, because we don’t know how quite yet
    • Organization:
      • Master spreadsheet – ADD LINK to Quarter where this was already discussed
      • ADT_A01 is the most complete message structure
      • When an element can have more than one mapping, duplicating the row, making sue the mapTo name is unique (unless something actually maps to the same element on FHIR)
      • In some mapping, the resource that is being mapped to MUST include a reference to a specific other resource
      • Using comment functionality for the specific cells to get community feedback
      • Some questions:
        • MSH-9 issue – need 2 values to map to FHIR resources
        • How to use message definition in FHIR
        • Using datatype flavors to map based on the v2 field context as appropriate
        • Looking for example to get extension for messageheader.timestamp
      • Review specific segments
        • OBR:
          • When OBR-2 and ORC-2 must map to the same FHIR element, because they represent the SAME construct in V2?
            • When both are populated, then use OBR-2
            • If OBR-2 is not valued, but ORC-2 is valued, use ORC-2
            • If neither are valued – depends what message structure this is for ay be error or ok
            • Go to the nearest relative segment in the tree
            • Do we need to create groups in all v2 messages first, before we can handle that, or should we just parse based on intent – so add the grouping at least in the message definitions:
              • We have SGH and SGT – for the instance
              • Or use the CHOICE construct that forces you to do 1 out of the list of the choice options and consider these as groups, that currently have ONLY 1 segment
              • Or can we tree the display sequence to create the grouping
                • Numbers for the next level
                • Alpha characters for choices at the same level
                • Use this not necessarily for message structure representation, BUT for use as reference to the specific level of the segment we need
              • In Germany you can have 1 ORC and multiple OBRs – deal with tis on the next round, when we are looking at more constrained profiles
              • For V2+ we will need to find a good way to represent choice
              • Useful first step it so illustrate the problem- in LRI guide examples for parent child linking in micro example (OBR-26/OBR-29 linking)
                • NIST may have java code written to express this kind of linking
              • serviceRequest is really initiated by the fact that ORDER begin is there, but without a specific field referenced
              • in ORM, when patient is not valued, then it could represent an order on a specimen that is not from a patient – in FHIR the subject is location reference in this case (not sure how that works on the v2 side)

Q4

Chair:  Riki Merrick

Scribe:  Riki Merrick

Administrivia

  • Should we make a policy to lock pages after we approve them – probably – maybe EST can make a policy about this – David to take back to EST
  • Set up a Co-Chair call – Lorraine to do a doodle – target week of 9/30 and 10/21
  • Handling Expired STU – need to be re-balloted, but we don’t need to do a NEW PSS – create a list of all the ones this applies to and request set up for NIBs
    • #1010
    • #902
    • #1009
    • #1067
  • Project insight review:
    • Tell Dave update the milestone date used in reports to use the date used in workgroup health instead of the ballot label - @Riki to do
    • #1339 = Co-Sponsor = SPL = awaiting TSC approval = in BRR
    • #682 = Specimen CMET – Motion to close and archive this project – Lorraine, David, no further discussion, against: 0, abstain:0, in favor: 4 – still need to update in project insight – had issue with access to edit
    • #1068 = Lab Order Conceptual Model – still need to do that – is listed as STU- accepting comments (based on LOI and LRI IGs – talked about using it for input to workflow / task development – need resources for this project – change milestone to May2020 and end date to May 2022
    • #1335 = LIVD – update label to May2020, end date May2023
    • #1450 = Re-affirmation on Lab V3 – was just passed in re-affirmation ballot – change status to Normative- notify, update milestone to Jan2020, so that we can update the status, end date Sep2024 – close project once
    • #1539 = Lab Models – profiles for work with CIMI – has not gone to SD – @Riki to look at PSS and follow up accordingly – update milestone date to 2/15/2020
    • #1096 = EHR-S FR for LOI – keep on hold? – the underlying FR has no indication that it was ever implemented - @Riki to put a topic on a future WG call – next milestone Sep2020, end date Sep2023
    • #1097 = EHR-S FR for LRI – keep on hold? – same as #1096
    • #1010 = Ordering Service Interface – expired STU comment period – take to informative ballot; next milestone date = May2020, end date = May2021, status = informative – preparing for ballot
    • #1095 – EHR-S- for LRI R2 = STU - expired in 2018- request 2 year extension - @Riki to make a publication request and then review the comments and so STU update – next milestone: Jan 2020, end date Jan2022
    • #1453=DICOM to Specimen DAM and SPM mapping – mapping has occurred, is on specimen call agenda – push milestone to Sep2020, end date Sep2021
    • #1481= V2-FHIR – milestone Jan2020, as that is for comment ballot in Feb2020; normative ballot May2020, end date Jan2023
    • #1512= UDI pattern R2 – we have crossparadigm R1 in product grid was published Feb 2019 –verified that it is for R1 – can close project =actually 1369 is for R1 – this one is for R2 @Lorraine need to talk to Dave about bringing this back to status = normative- ballot reconciliation, milestone Jan2020, end date May2023
    • #1413 = Eyecare – on hold but have not heard anything for 2 years – so close
    • #792 = LRI R1 – has been named in MU2, but really has been superseded by LRI R3 - @Riki to get guidance form TSC on what to do with this one –update milestone to Jan2020
    • #902 = Nutrition Order V3 messages – expired Sept 2018 – normative ballot, or drop – no implementers - ISA 2019 has it listed – so add to informative bucket, status: informative – preparing for ballot, next milestone Jan2020, end date Jan2023
    • #952 = FHIR resources for OO – need to keep this open for FHIR maintenance @Lorraine to follow up with TSC how to handle, since some are normative – milestone: May2020, end date: May 2025 – since we have #1115 change status to archive
    • #1009 = Nutrition V3 – facilitator change to Becky Gradl, status: informative – preparing ballot milestone: Jan2020, end date: Jan2023
    • #1067 = Lab Order Conceptual Spec - status: informative – preparing ballot milestone: Jan2020, end date: Jan2023
    • #1081 = FHIR resources for Nutrition care – milestone: May2020 (match FHIR ballot), end: May2023
    • #1113 = FHIR profile for Lab Results – change status to archive
    • #1115 – OO FHIR STU monitoring and maintenance @Lorraine to follow up with TSC how to handle, since some are normative, milestone May2020, end date May2023
    • 1199 = Comparison IHE to US Lab IGs - the work has been completed – if we are going to make changes based on this, will need new project, if changes are to be made
    • #1362 = Reaffirm the Cardiac device – expired past 5 year period @Lorraine to find out, if we can just do a reaffirmation for this – needs to move through process @ Riki to bring to ASD, after clarification; milestone: Jan2020, end Jan2023
    • #1370 = transfusion and grafts on FHIR – biologicallyDerivedProduct work, so is active, milestone: May2020, end: May2023
    • #1238 = UDI IG – status informative – reconciling – check with Marti, milestone: Jan2020, end: May2023
    • #1292 = Specimen DAM – status has been published milestone Sep2022, end Sep 2025
    • #1496 = FHIR DME – PSS still in approval process – milestone May2020, end May 2023
    • #1369 = UDI pattern R1 – is published, so archive

Motion to accept the above updates Lorraine, Dan, no further discussion, against:0, abstain: 0, in favor: 4

Meeting tomorrow Q1 = M107 – will find out if Hans is around – if yes will hold, if no Riki will send note to the list of cancelation

Friday - NO MEETINGS

  • No labels