Skip to end of metadata
Go to start of metadata

Monday Sept 16, 2019

Q1 and Q2 = Plenary


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  – 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


  • 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


Joint with FHIR-I - see there for minutes

Tuesday Sept 17, 2019


Chair: Hans Buitendijk

Scribe: Lorraine Constable

Hosting HCD

Summary of Health Care Product

  • See powerpoint on OO Product Pages Healthcare Product
    • Need to fix boundaries and scope between the related resources and progress them in the maturity model 
    • Review of the diagram. Dark green OO owns, light green are related. Light orange are items we think we need, but do not yet have resource proposals
    • Eg – we may need a BiologicallyDerivedProductRequest similar to a MedicationRequest.
    • Also need to relate to pharmacy resources and definitional resources
  • Question – what do we do with DeviceMetric 
    • Document being developed to describe the details of the definitions. Once agreed they will be added to gforge and applied.
  • Reviewing Device Use Statement and related use cases, and the definitional corollaries to the entities.
  • Settled on the agreement that SupplyRequest is not patient specific – moves of materials / drugs out of band to the patient. DeviceRequest and MedicationRequest still exist as patient specific
  • Reviewed the path that starts with a specimen or procedure to create a bioligicallyDerivedProject to then ultimately be administered. Still walking through the use case for BloodAdministration
  • Nutrition on FHIR group is progressing the nutrition use case. Still need volunteers to progress the BloodAdministration use case.
  • Meeting on this topic – Monday afternoons 3 PM ET. Discussion on how to get this done and moved forward


Question for documenting device use or why device not used in measures. Do we use DeviceUseStatement, Procedure, or Observation. MedicationUse drifting to merge with Medication.

Drifting to documentation of what is there, not the prescription, administration or request.

Ie – patient is using a wheelchair. Not the request for the wheelchair

For CQI, it is important that it is “applied/administered”, as reported by clinician. Sounds like more the Procedure. Still tbd for DME (Durable Medical Equipment)



Description about difference between the two. DeviceMetric is about state: Calibrated? Attached to the patient at body site X

Comment about observation usually about the patient

  • properties about the type – attribute set and then only changed based on reference
  • Not to be mixed with observation which is the output of the device for a particular subject

Observation can point to the device that created the observation (0..1). How do we express the device metrics as appropriate

Discussed the reference in Observation to Device and DeviceMetric – is the definition consistent with using DeviceMetric for the definitions 

Need to enhance the definitions to clarify when / why you would use DeviceMetric here.  Need a Gforge tracker to track the work.

Action: OO will create a tracker to ask HCD for clarification on DeviceMetric / source and parent definitions, plus to make parent 0..1


Gforge tickets

23845 – Brian supplied 3 examples , one with UDI, one with multiple specializations, other does not

Motion to accept the examples, with the proviso that Brian will fix the UDI DI value, for inclusion in the build.  Lorraine Constable / John Rhoads Against 0 Abstain 0 In favour 25


Chair: Hans Buitendijk

Scribe: Lorraine Constable

Hosting BR&R


Should we add to Observation or just DiagnosticReport? That gives just one place, drives consistency. Other argument is when the blob/image is the actual result.

Comment – these are slightly different use cases

Kathy – use case is where there is a “result bucket” and the document is the actual result that may have been scanned and is the actual result. Implemented R2 where this exists, but in r4 does not exist

  • 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


Substance Definition – Substance

Reviewed the proposed Substance Definition entry; matched to Substance. Discussion of where Substance.code matches in SubstanceDefinition, which would go in SubstanceDefinition.code.code

Should we add a reference to SubstanceDefinition.

Action Create a gforge tracker to change code to definition which is a choice of Code|SubstanceDefinition. Also look at Device / DeviceDefinition to see if the pattern holds there.

Request to obtain the list of elements FDA thinks needs to be added to substance, so we can review and determine which resource it should go in, or both. Jean Duteau / Katherine <I missed her last name> To provide 

Follow up with Rik on Healthcare Product calls.

Nutrition Connectahon Update

  • Unfortunately partners did not show, but will be in Sydney
  • Worked primarily on documentation and examples.


Chair:  Robert Hausam

Scribe:  David Burgess


Chair:  Riki Merrick

Scribe:  Riki Merrick

  • Agenda review = II declined
  • valueAttachment
    • Cerner had implemented this for lab for referral studies to attach the lab report pdf for genomics reports or flowcytology studies
    • Are extensions version specific? It will probably propagate to later versions, for pre-adoption is allowed, but would be considered custom for those versions, but at least it is standardizes
    • If it is all transcribed would be diagnosticReport.presentedForm – what if only partial or no extraction; shouldn't it still be in the same spot, because you could manually abstract and add or the lab could already have sent you the discrete data
    • Example:
    • Normally diagnosticReport has several observations
    • Data absent reason – could we add a value to the valueset there to indicate to refer to presentedForm element
    • We may still need valueAttachment for graphs produced by instruments
    • Labs think of the pdf as a result – in V2.x this is ED datatype in OBX-5
    • Describe the use cases:
      • Graph off instrument
      • Pdf of referral lab test that ONLY has pdf scan
      • Pdf with additional discrete results that are also in the pdf, but are provided by the sender
      • Pdf has been sent without discrete result and it is being forwarded
    • Media/DocRef:
      • They have been merged – see report on OO Main Call Notes August 29, 2019
      • Align status between documentReference and diagnosticReport
      • Diag: ADD ALL Values here Registered / partial / prelim
      • DocStatus: is missing appended, registered (not sure that would apply to documents), partial, unknown, canceled / corrected
      • As a recipient of document how do you treat unknown status
      • Should documentReference be renamed, since it now objectReference
      • Do we want to rename docStatus
      • Difference in category value set between these 2 as well – is often used to decide routing; not comparable – LOINC being used here, but it seemed you cannot rely on the mapping to this code that was not specifically designed for this. Category repeats, so could create more than 1 hierarchy so you can identify the type as well as the domain where it is used
      • UScore DiagnosticReport extension – add the LINK?!?!
      • Examples diagnosticReport urinalysis JSON
        • Reference should be to the ID of the observation not the "organization/urine-color" and it should not have the display there
        • Reference display is just to help give an idea of what resources are being referenced in the example report - it would be nice to have an example that has ALL the parts of the diagnostic report available to better understand the relationship between all the referenced resources
        • Using the = negative as part of the display section is misleading that the reference could identify the test and display the result
      • Adjourned 4:51 PM EDT

Wednesday Sept 18, 2019




  • 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."


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


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


  • [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


Chair: Lorraine Constable

Scribe: Riki Merrick / Lorraine Constable

  • Joint with II, CG, BRR
  • Agenda Review
  • Same session for Syndey for CG, II and BRR - YES!
  • Healthcare Product Recap
  • Cancer specifications for Genetics (M-codes, v2 IG, and FHIR)
  • Clinical Genomics
    • close to publishing Genomics reporting Implementation guide
    • Changes to observation in R5:
      • will replace current extensions in R4 that will result 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
    • no updates


  • Healthcare Product recap
    • Slide from Hans
    • Resources owned by OO need clarity of scope boundaries to other resources
    • Need to up FMM levels up and improve statements in introduction
      • Focused on darker green
      • Less on lighter green
      • Orange and mauve don’t have resources yet
        • NutritionIntake
        • NutritionProductIngerdientLable
        • BiologicalylDerivedProductRequest – or does MedicationRequest cover this space
      • There have been several gForge trackers to reference BiologicallyDerivedProduct
      • There is a word document summarizing the introductions to all the covered elements – expect distribution for review in the next few weeks
      • MedicationStatement – transitioning to MedicationUseStatement
        • Based on
        • Becky will meet with Rx WG to make MedicationUseStatement more generic, if possible
      • How do resources around
        • when attached to patient =
          • MedicationRequest
          • DeviceReuqest
        • Move medication without a patient
          • suppyRequest
        • Difference between Substance and SubstanceDefinition
          • substanceDefinition is about the characteristics of the substance
          • Substance is instance in a specific "barrel" before used in instance of medication
          • MUST have series of use cases to clearly describe the boundaries between these use cases
            • Ideally like in ClinFHIR define the use cases and list all the
          • FHIR is not being clear about the information models we are using – we are using the resources
          • In OO related resources we will have a lot of definitional resources, while – BRR owns the substanceDefinition
            • We are trying to define patterns for resources that are similar
            • What is the difference between definition and knowledge in the resource names?
              • Knowledge would be interpretation / comment on something
              • definitional is defining attributes that don’t change
              • the definition patterns in the CDS area are actually more knowledge may need to discuss this on larger organizational level
            • What all is comprised by biologicallyDerviedProduct – why 2 boxes?
              • Use Supply request for tissue (not likely, because the supply request will be for a specific patient when it is identified) vs blood product (can deliver to blood bank on ward, before it is assigned to patient)
              • May need definitional resource here as well, when you want to describe what kind rather than a specific instance
              • Is breast milk a biologicallyDerivedProduct?
                • Had discussion around that, only used as expressed breast milk – so treat similar to food
                • Is there need to test compatibility, then consider biologicallyDerivedProduct
              • Calls are Mondays 3 – 4 PM – ADD LINK to confluence
            • CG update:
              • Publishing Clinical Genomics Reporting FHIR IG soon after 2 cycles
                • The will replace all extensions in observations along with valueset, so need to deprecate these – as well as the examples
                  • One of those is a very bad example – could we do that as technical correction in R4? = example 3 = ADD LINK:
                    • This has only a performer, just text for a note, but no observation.value
                    • Deadline for technical corrections is next week Friday = 9/20
                  • A lot more examples will be in the Clinical Genomics reporting guide – could we point to those from here?
                  • Is there a way to label the examples and extensions to indicate that they will be deprecated in R5 – just like it was done for the profile with
                  • Lorraine will follow up with Grahame
                  • CG will need to get the list of items these corrections apply to
                  • And then send the publication request for technical correction to Wayne
                • In the old deprecated profiles extenstion.geneticGene there is valueset binding to HGNC
                  • This is owned by OO – can we do that for R5? Yes – enter a gForge items – ensure that this one MUST make it into
                • Have observation profile that groups observation should we reference just the grouper resource, or do we need to have the observations that are part of the groups
                  • DiagnosticReport vs observations for these kind of groups
                  • DiagnosticReport can include nested panels
                  • Make examples for this and send to zulip chat and send that link to the OO co-chairs
                • Tumor mutational burden – is a computational result an observation
                  • In observation method is codeable concept – but since this is often a longer text that is described in a protocol but may include alterations for this instance – create a tracker for this
                  • What is the reason for method cardinality 0..1 – should be 0..* maybe
                    • Use case is listing the analyzer, software used there – in the V2 world there is OBX-18 for equipment
                      • So device, but that is also 0..1 – should be 0..*
                      • Bring this up with FHIR-I to get feedback on what we can do normative resources
                    • Could we use a reference to SOP / protocol = planDefinition?
                      • Make method a choice:
                        • Codeable concept (existing)
                        • Embedded text
                        • Reference to planDefinition (or something more detailed)
                      • OR create an extension for NEW element methodProtocol to cover these situations
                    • For publication – how to make sure the editor is listed – Jamie has worked hard on that
                      • IG Publisher should have a section for editors/ authors etc – Riki will make that gFOrge
                    • II
                      • II Co-Sponsors updates:
                        • 1453:
                          • ADD the link here
                          • Set up
                        • 1010:
                          • Catalog project – still ongoing and getting resource proposal approved – (catalogEntry)
                          • Focus so far has been lab and pharmacy
                          • Calls are Fridays 12 -1 PM EDT
                          • II would like to have connectathon track in May 2020
                          • LINK TO WIKI that has the use cases
                          • II to add their use cases here
                          • Schedule a call specifically for II topics – Francois to do
                        • ImagingStudy is not good at referencing a specific image of the study
                          • Would you need to get down to the region – may be use DICOM instead of FIR resources
                          • Also linking to specific observations in
                        • IHE has used documentReference to replace XDS
                          • Why not use DiagnosticReport for this with the actual observations
                          • It is used as an indexing for FHIR artifacts
                          • Next cycle will need to work on radiology reports
                            • Once we clean up HL7 base resources ow to provide feedback to IHE
                            • Discussion in OO tomorrow Q2
                          • category and diagnosticReport.category
                            • In observation the list of values is very broad
                            • In diagnosticReport has more granular list than observation, but is missing quite a few terms
                            • It is exemplar binding – could we make it preferred?
                            • Regenstrief is encouraging to use LOINC parts form the class part for category
                              • Will publish this hierarchy and include a category for labtests as a class part in next LOINC
                            • Category will be used for different purposes, so category can be repeated, but it will be used very differently by different organizations for the same purpose – in practice, so is it worth the work
                            • If we can provide codeable representations for that
                            • One reason for difference was that diagnosticReport was used for surgical report, though that code is not in that value set

Adjourned at 12:20 PM EDT


Chair:  ???

Scribe:  Riki Merrick

  • Agenda Review:
    • PC no specific topics
    • FHIR-I no specific topics:
  • SD topics:
    • Have several gFOrge related to docRef assigned to John Moehrke
      • SD gforge tracker – gF#19873
        • category and documentReference.category - sufficient terms in value sets and overlap
        • doc ref now includes media, so is for any objects- might not fit in document classes and is NOT limited to documents - LOINC part codes for are used in observation.category and diagnosticReport.category
        • also valueset are example only
        • IHE used documentReferennce for XDS purposes, so only high level categories
        • Category was intended to be used for searching
        • In base will always be example, in profile could tighten terminology binding
        • No more media resource – attachment datatype was updated to cover media attributes (provided the rest home place for media attributes) – docRef is unfortunate name
      • Make new tracker for OO on docRef to say in sync with SD
    • CDS/CQI no specific topics:
      • status in R4 this has mixed use: expressing the status of the resource ="JSON status" as well as when active = implanted device / inactive = explanted, Entered in error = that would apply more to the documentation about the thing = resource
        • need to separate that out
        • Update definition to device.status to be sure this reflects the resource status, so entered in error is appropriate here
        • Update the value set term descriptions for active and inactive here
        • Status and reason for the status
        • Different kinds of statuses
        • Intent "resource".status describes the status of the thing the resource is representing
          • Operational status = turned on, turned off – this is truly about the device
          • Association status = implanted / explanted relative to the patient, absorbed, - may not apply to all devices we describe in FHIR
          • Logistics status = in inventory / dispositioned etc – not sure this is needed outside of specific supply workflow – want to get feedback
        • Option 1:
          • Attributes for all
          • operationalStatus
          • Reason
          • associationStatus
          • Reason
          • logisticStatus
          • Reason
        • Option 2:
          • make backbone element for status of some kind, that would have a value
          • and reason and the valueset in the codeable concept terms will
        • Option 3:
          • 3 attributes in the backbone for status:
          • Type = operational / association / logistical - other
          • Status =
          • statusReason =
        • Why is deviceMetric not used for this = make this option 4;
          • and operational status = device.status; operationalStatus is already part of deviceMetric
          • Personal devices does not use device metric at this time
        • Rick's option - #3 sounds the cleanest – but it may create a new pattern we have to consider not following the devicePattern (participant) – is ONLY a Boolean (does that mean on, off and where would entered in error and unknown go? = entered in error is = false)
        • what does the definition of whether the participant is active or not = what would it mean if the participant is the patient?
        • If they are explicit attributes easier to see, but harder to add new ones
        • The deeper that is buried in the resource is harder for coders to use and provides risk that it will be implemented incorrectly
        • When component was merged with device there is property that has a type, but not a reason – then this becomes a terminology problem and extend the property attributes to add reason
        • Option 5
          • Change device.status =>
          • property.type need to clean up the definition and update the terminology binding – should it really be extensible? – is there a gForge for this
          • Can device folks create a few examples / scenarios and show each option?
        • Want to vote on this Thursday Q1 about 45 minutes into the agenda
      • Implantable devices – can we include body structure where the device is being implanted? The reference is in the procedure. How do you document when a patient comes into the practice with an artificial hip, how to record – maybe deviceUseStatement? Submit a gForge to describe specific use cases to get more discussion
      • In PC talked about procedure being the act as well as the statement that it happened – if the patient reports that they stuck it to the arm (insulin pump for example) – would that then also happen to medicationUsage (formerly known as medicationUseStatement)? MedicationUsage is more generic – not specific like 1 aspirin every night for 5 years – do we need a usage patterns
    • gF#20932:
      • has link to zulip chat in OO ORUmapping
      • how to document who should be cced on the results – the serviceRequest implicitly
      • for composition we have and extension in an IG, that will be moved to core for R5 for informationRecepient – could loosen that binding from composition a broader context – Hand and Rick will work on the gForge to accomplish and Hans will
      • what about communicationRequest = they need similar ccs for example
      • restriction.recepient definition is confusing – is that the patient or the ordering provider – the name restriction is confusing as is the "For whom" = will take up, when we have workflow task guy – ASK ERIC


Chair:  Hans Buitendijk

Scribe:  Riki Merrick

  • v2-to-FHIR
  • Agenda review
  • PA and FM not here
  • V2 to FHIR mapping
    • Only mapping elements that are used, not everything available in v2
    • If no core element or extension recorded at core level for a to be mapped attribute, then we suggest creation of an extension – and hopefully this will be re-used
    • We have tools that convert our mapping spreadsheet to actually map message instances to FHIR bundle for ADT messages
    • Will use the ballot process in Feb2020 for comment – feedback on format and approach is goal – some mapping would be good
      • Will use FHIR IG style
      • Originally wanted to map datatype and segment, but realized that mappings may depend on the message context
        • Creating datatype flavors for target mappings to accommodate that
      • ADD LINK to the inventory spreadsheet
      • Community review for 2 weeks – announced via zulip and listserve
        • One comments are applied, then in "ready for ballot" bucket – but can be updated still, when needed
        • Also creating mapping on valuesets – but this will need vocab review
          • Several V2 mappings may not be 1:1 – in some cases needs to add, but in some we may want to extension to cover what the term is
        • Right now the mapping is V2 to FHIR – someday may also have the reverse, but that is not the focus right now
        • Microsoft has built a tool that harvests the mappings from confluence = connectathon outcome J
        • ADT_A01:
          • Left hand side v2 – middle = condition where it applies - right hand side FHIR
            • If no condition listed, then it means, if valued make mapping
          • Display Sequence is where the segment is in the V2 message
            • If the same number each segment that is in the message at this location MUST evaluate all conditions for each segment instance in the message that are defined for the segment in the message definition
          • Created specific datatype for several attributes
          • References:
            • When role is identifying a related person to the patient MUST include the reference to the patient that is listed in the immediately preceding list it as Patient[1] – must not be the same as PID-3 necessarily – but patient[1]ID MUST be processed before you can apply this reference
          • Segment
            • Column H is for tooling to pick up all FHIR resoucres that exists
            • Column I is for planned FHIR resources that need to still be created = extensions
            • Derived mapping – if you want fixed values in the FHIR attribute column
            • Need to map the Telecon to use code either home vs business
            • [2] indicates the need to support multiple occurrences of the attribute, but it does not mean the work phone number is ONLY in the second instance
            • If we map to FHIR resources, are we watching for mandatory elements in the FHIR resource
              • Have not looked at these
                • no content in V2 to required element in FI+HIR
                • optional in v2 to required in FHIR
              • What is in github?
                • Spreadsheets (googlesheet) is the source of truth
                • Confluence tables are also not up to date – that is where we stated
                • In github is just as backup / version control in the future – at minimum after the first publication
                  • How to handle the explanatory text?
                  • Potentially use FHIR to represent the underlying content (conceptMap), similar to UTG
                • Have Q0 discussion for specific tooling for mapping
              • For ballot will need some v2 examples with the transformations – have tooling to do that and that should be part of the ballot content for review
              • We have test cases for these messages – but that should help find where the issues are, we missed so far – can create standard V2 messages that mapping tools have to demonstrate they arrive at the prototype FHIR resource in the future!
                • Are we using FHIR resources for persistence vs just for transport
              • Progressing through the V2 message use cases based on common usage – at the standard level, this does not account for the variability in V2 implementation
              • We have this based on V2.8.2 – will update to V2.9, but we are aiming for cumulative view, we are mapping withdrawn fields as well, so that you have the full possibility (will need to sometimes look up what the definition was at time of deprecation)
              • What about mapping implementation guide constraints – commonly used profiles can create extended maps for those = how to do that for national extensions or for IHE etc and display ONLY the delta – will need to be worked out in the future – document the fact that this is of interest, so we include that as during design considerations
              • ADT_A01 is started to be run, but there are quite a lot of things missing from the generated
              • VXU also has amount done, but not cleaned up (comments and discussion notes still there)
              • Next up: ORM and ORU – missing the ORC, OBR and OBX
              • When do we ask for extensions?
                • Either ask WG now, if we are pretty sure we will need it
                • Wait for ballot feedback before we ask
                • We think after community review is best timing, so it's not too late, so we can document it in ballot
                • There may be extensions in Implementation Guides that are already available to request scope expansion – how can we be sure we can search for all of these that exist – ask FHIR -I
              • Timeline plan ADD link <WHO HAS THAT>??

Thursday Sept 19, 2019


Chair:  Hans Buitendijk

Scribe:  Hans Buitendijk


  • Connectathon update
  • Tooling and ballot update

Connectathon Update

  • There is a spreadsheet that collates links to all the mappings
    • having the links in the separate cells helps to maintain the hyperlinks in csv download
    • we may have to separate hyperlinks out in the mapping spreadsheets for the datatypes
    • spreadsheet has tabs for messages, segments, datatypes etc
    • make sure the names in the hyperlinks are correct to help with proper generation of the URL - action item
    • 2 columns for condition in all spreadsheets for consistency – one for computable, one for narrative
    • Display sequence has been fixed, where there were repeats
    • have 2 columns for the FHIR attribute mapping:
      • in column H existing FHIR attributes
      • column I shows proposed FHIR attributes - once these are created they migrate to column H
    • using "=<terminology>" has not caused tooling issues - if you don't have that, then must look at datatype mapping column
    • maybe we need to create a separate column for fixed values (especially if we have fixed value in datatype that is being pulled into the segment mapping from another sheet) - Robert will see, if his tool finds any
    • In ADT_A01 reference point to the FHIR version of the attribute rather than the PID – this still needs to be cleaned up in all other spreadsheets
    • Using Roberts mapping tool with test messages to clean up the spreadsheets
    • Grahame questions:
      • Why use ANTLR instead of FHIRpath – it seems to be more readable to all
        • Can we use FHIR path in the computable column?
        • Add in column for FHIRpath – or use the narrative column for the old computable statements
        • Decision: Add in the FHIRpath column between ANTLR and narrative – Craig will update the other sheets
        • ROL segment, PRT and same for OBX may have multiple occurrences will need to be more explicit about the occurrence that is the reference – we could use the PRL datatype, but that requires instance pointing – how to do that
          • For getting information about parent child linking (OBR-26/OBR-29) and use of OBX-4 look at LRI guide (ADD LINK)
        • Craig has been working on ORM and ORU - added a few new datatypes and several new segments and message structure - still has a lot of comments
          • To run some test cases we have loaded some ORU test messages into the test library – ADD confluence page link

Tooling and Ballot Update

  • Grahame is working on moving the spreadsheet content as csv parsed into conceptMap and structureDefinition (1:1)
    • Issues in structureMap creation were based on spreadsheet context implication
    • Generated IG from that
    • Left extension in conceptMap stating that this conformed to the spreadsheet context logic?
    • Rendered back into spreadsheet format
    • Spreadsheets are NOT good for version control, so did not write automatic downloads
    • Csv file drops the hyperlinks = add a column to house the URL? – not needed, as long as the name in the segmentMap field
    • Can also download as excel spreadsheet – also issue with version control for this
    • To support version control UNTIL we drop content into gitHUB to pull the IG content into
    • Ballot timeline
      • in Feb2020 for comment
        • format and conceptual approach
        • not on the mapping content
        • include the test cases and other artifacts that are needed
        • not sure the IG publisher can handle v2 messages by Feb2020 ballot
      • In May2020 content ballot
    • has rendering from IG perspective to look like spreadsheets - so we can now start writing the IG

Next WGM keep this Q0 for this topic, or move into the regular session in OO?


Chair:  Hans Buitendijk / Riki Merrick

Scribe:  Hans Buitendijk / Riki Merrick / Lorraine Constable


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


  • Francois shares his slides 
  • And rationale for the design of catalogs:
  • 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 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 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 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 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 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 0..1 boolean active|inactive (covers deleted and entered-in-error) - focuses on the active state of the resource on a server effectively.
      • Update value set (needs to be fixed regardless) for operational and association 
        • seems to work for operational, but not for association that well.
      • Update value set 
        • on|off|standy|etc.
        • implanted|explanted|attached|etc.
      • Add 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 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
      • 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


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

      • Device resource has statuses and in mapping to the pattern needs to show which of the statuses applies to the 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: 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


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)


Chair:  Riki Merrick

Scribe:  Riki Merrick


  • 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 Sept 20, 2019 - NO MEETINGS

  • No labels