Skip to end of metadata
Go to start of metadata


OO WGM 201905 - Attendance Log

Monday May 6, 2019

Q1 - OO/CIMI

Chair: Lorraine Constable

Scribe: Riki Merrick

  • Agenda review
  • New quarter next meeting – will talk to Galen; anytime through Wednesday: OO options are Tue Q3 or Wed Q4 => Tue Q3 for Sept – maybe leave it there going forward for consideration
  • Model Section id DiagnosticReport with focus on impression:
    • org/en/info.cfm – get from Richard
    • structure example for radiology report
    • similar to CDA, but that uses composition
    • can model this as profile on observation vs using a backbone element
    • if not diagnosticReport then could use composition
      • this discussion is still open
    • have results that link back to sections in the imagingStudy
    • If we normally do this by CDA, use composition vs if more like lab result, then
      • In US radiology is V2 ORU messages – a lot of these
        • There are some OBX groupings (either with OBR or using OBX-4) to order this a bit more
      • In CA and Europe use of CDA is more widely used – similar to Anatomic Pathology Structured Report
    • Create DiagnosticReport and profile composition to crreate sections
      • Maybe make the result in Diagnostic report a choice of observation or composition?
      • Need observations PLUS impressions PLUS Summary – doctor always reads the impression first, so that needs to be very obvious
      • It seems the FHIR resource does not currently represent real world diagnostic reports
      • If you want to query diagnosticReport need to get the entire report, not just a part of it, so should we not keep the resource contained
    • Or should we create a backbone element called section?
    • Since there are more discussion
  • LabModel – spreadsheet that links to the FHIR representations
    • There are 88,000 LOINC labs
    • Create a profile for each LOINC = Even if we take top 2000 (don’t cover clin genomic tests) we would get a combinatorial explosion of profiles
    • Alternatively could set up this spreadsheet that has the LOINC descriptions and put that into the validation machinery – can use more of a prototype of lab profiles, but tha tis not currently part of the FHIR machinery
    • Create invariant for each lab, which is in-line with current FHIR validation machinery
    • Need to consider the work we have been doing in catalog / LIVD = observationDefinition
    • Need to ask how FHIR wants to handle this kind of thing
      • Profile on observation – for quantitative lab results
      • observationDefinition
        • have large number of instances you need to validate use definition
      • invariant (on observation) = if code = LOINC x, then – binds to units of measure = profiles observation
    • Question: If an observation is sent, do you use the observationDefintion or the profile on observation?
      • This should be a question for FHIR-I
      • We came up with Definition resources, to remove the requirement to have a profile – definition is modeling the
      • Might have a system based on these kind of patients and want to define what the normal ranges are for the results of a test
      • Definitions allow you to give you more information across a range of values for particular patients / specimen information / specimen condition etc
    • Use case requested by CIMI:
      • Define the structure you will be receiving / ranges, datatype, units, bindings
      • Agree there are a small number of structures that define the type of lab test
        • Need to capture the specific valuesets for coded results / units allowed
          • Invariant on observation (using FHIRpath for logic expression)
          • Profile on observation
          • Observationdefintion
        • Where would you contain the invariant?
          • In profile for coded labs- still have x number of LOINCs in the invariant lines in the profiles
        • There are 2 questions:
          • Difference between profiles and definition
          • Shorthand to express large number of profiles = this is a question for FHIR-I
        • Use cases:
          • What is the target for definition?
            • If I develop an app that queries for test x – need to have the units, expected reference range etc = that should be the definitional resources; the lab needs to decide what the reference range that is applicable for the particular patient – that should be in the instance – you could say this is age and sex defined reference range – defines the variables that will further specify the
          • Examples for invariants – lab-invariants-v2.html 
          • Problem with use of invariants is that it is easy on simple constraints – like just one attribute
            • But need to include some more ranges – magnitude of number, abnormal value set, coded elements valueset
          • Use to have dictionary tables based on LOINC properties – this construct does not exist anymore – will need to ask
          • Mark has built a resource that reads a table and can read in the content
          • Definitional resources have now been tested in 3 connectathons – going ready to go back to FG to get to
          • Conflating 2 things:
            • We want to represent rules on how to create the messages to send across the wire
            • Families of profiles what do we use to express that with the information that defines each instance that can be sent in the profiles
          • We still have to deal with 88,000 things
          • Use cases of describing what to order vs what to deal with the operational aspect
          • StructureDefinition is FHIR building block = definitional resources are outside of that
          • We think profiles are not feasible
            • When we have structural differences create a profile – quantitative / ordinal / nominal
            • When we have details within the profiles
          • This happens also at medication ordering – nutritional ordering
          • NEXT STEPS:
            • We are looking for how to do X when it looks like this = definitional resources
            • Need to bring this back to FHIR-I to get guidance on:
              • when to use definitional resources vs profiles
              • how do you validate resource instances using definitional resources
  • OO meeting with FHIR-I next quarter for OO planning purposes
  • Election in OO – 4 Co-Chairs are up for re-election
  • CIMI will still join OO WG calls: next topic will be sections for reports; CIMI will give us topics, and times when they have them


Q2 - OO/FHIR-I

Chair: Hans Buitendijk

Scribe: Hans Buitendijk 

  • R5 Planning
    • Media/DocRef/Attachment/DiagnosticReport
    • Device(Definition) / Diagnostic Report
    • Vital Signs Sample Data

R5 Planning

  • Observation
    • What can move to Normative?
    • Search Parameters - some can go normative
    • Operations - not enough experience, but perhaps
    • Vital Signs Profile - not likely.  Not needed for ONC rule reference we think through US Core
    • Next step is to reach out to implementers on which search parameters and perhaps operations are ready to move to Normative.
  • DiagnosticReport
    • Unclear whether DiagnosticReport and Media/DocumentReference/Attachment relates.
    • Once Med/etc. is resolved, then DiagnosticReport
    • What is boundary between DiagnosticReport and Composition?  Discussion on what organizational structure is needed in DiagnosticReport.
      • Is it possible to have zulip/connectathon discussion on DiagnosticReport as profile of Composition.
      • If we go DiagnosticReport "as-is", we could and a composition like structure, or something along those lines.
      • Richard Esmond et al to prepare a sample/mock-up what it would look like and requirements.
      • Late May onto Zulip, first week of June 4 (14:00-15:00 EDT) in OO on FHIR.  Invite II to the meeting.
  • Device
    • Connectathon would suggest FMM2 based on feedback.
    • Tomorrow
  • ServiceRequest
    • Is at FMM2
    • Should this be the focus instead of Device?
    • For CDS this is a critical resource, while for US Core (only US focus) not as much.
    • Other example is BSeR focusing on referrals using ServiceRequest.
  • SupplyRequest/DeviceRequest
    • Resolving whether we need one, the other or both by considering making SupplyRequest support subject=patient.
  • Task
    • It's in Public Health in eCR, plus Da Vinci (CDex, etc.) pushing it.
  • BodyStructure
    • Various issues with that requiring attention.
    • Would an enhanced bodySite data type be better suited?  Would have to get alignment with FHIR-I.
    • Should we have a body location?
    • Some aspects could be resolved using Condition.
  • CatalogEntry
    • In debate on how to finalize modeling.
  • DocumentReference
    • If it goes where currently anticipating, than likely needs to end up with OO.  Just a thought.


ChargeItemDefinition

Not today

Request Resource Alignment to Patterns

  • As CDS is implementing, finding variances in request resources.  Some are legitimate and need to continue, while others would be candidates for alignment with the pattern.
  • Intent was to coordinate with workgroups to determine which changes to generate tracker items.
  • Workflow is also working on that.  Build warnings are starting to come up as well.
  • Clinicians on FHIR is reviewing, anybody welcome to join
  • Use OO on FHIR as the target forum to discuss potential variances that need to change, and resolve actual gForges first there.

Observation(Definition) Profiling Approach

  • Target is plug-and-play interoperability.
  • FHIR Resources provide many different approaches to achieve the same.
  • Attempting to get consistency where appropriate/necessary to make it more plug-and-play.
  • Given volume of Lab tests, could do the necessary profiling many different ways.
  • Could use invariants, dictionary tables, etc.
  • ObservationDefinition could be used as well.

Q3 - OO/CQI/CDS/CIMI

Chair: JD Nolen

Scribe: Riki Merrick

  • Agenda Review = all FHIR Trackers
  • #17164: How to document when something is not given? ADD LINK
    • Lisa Anderson (Joint Commission) – will represent Lloyd; came from
    • Use case baby got breast milk
    • Want to know what was administered – measure is for breast milk only
    • Becky Gradl: Nutrition call had discussions about these 3 items, with Margaret Dittloff giving input of historical knowledge
    • this was to support the measure of baby gets ONLY breast milk – so think we need to look for documentation of baby NOT getting TNP or formula – also how do you record to add nutrients to a nutrition order – it is currently part of oral order
  • #20661 How to document intake of infant intake (formula or Total Parenteral Nutrition (TNP)? = move to Tue Q1, since touching healthcare product
  • #17167: ADD LINK
    • What are boundaries for adding new items to an existing oral diet order; can I update an existing order, or do I need to cancel?
      • In DAM decision was made to not update, but to delete and create NEW order, possibly to
    • Where should we document the outcome – this is not structural, but rather workflow related, so it is profile specific?
    • Will need to create a profile for nutrition intake – establish the direction for community to use
    • How is this related to device and substance?
    • medicationStatement – may need to profile that for nutrition intake
    • How do we represent these nutritional items
    • Healthcare product work is Tue Q1 – nutrition should be in there for consideration
    • Some of this belongs to PC?
    • this should become the profile on nutritionOrder
    • We have 2 topics:
    • When you change order for nutrition => make NEW order for example for change of consistency in order VS. supplements / nutrients additions may need to be treated slightly differently – those are treated as separate orders from underlying order;
    • Anything on top of “regular diet” should be additional order- similar to one time additions, vs modifications of the “regular diet”
    • Individual product vs type of food for patient (including modifier like liquid only)
    • If you want to prescribe additional Vitamin D, then needs to be included in the overall order
    • oralDiet has nutrient as separate
    • Is substance you administer or action of what to do, like eat more leafy veggies
    • do we need to differentiate inpatient and outpatient nutrition orders? – in V3 we also have patient preferences = in conceptual model these are - this is ONLY for long-term care setting
    • current FHIR resources are only built for inpatient setting
    • NEXT STEP to get answer to the first 2 trackers?
    • Do we need to make a specific use case / profile for inpatient or outpatient orders
    • Behavior prescriptions – Has that been tackled somewhere? – that is Patient Care topic
    • Boundary for OO: is it actionable by a system? – in V3 we have separate approach
    • Some of the outpatient prescriptions are actionable – for patients with food insecurities this will be a dispense based on this prescription
    • Things you can dispense and can set goal arund vs
    • Work out how to deal with outpatient order / recommendation, then revisit the decision about updating nutrition order
    • How do we document of one order with another? This would be more captured in task – one order instantiates a plan, and the new order will update that plan
    • We have concept of replace for documents in FHIR, would this apply here – is that important?
    • This is a point in time view. We are talking
    • One active general diet and 0 or more supplements
    • Next Step: for Friday call 2 PM EDT will walk through outpatient use case for nutrition order
    • Create a profile for outpatient
    • In use cases make sure we address how to model the nutrients AND TPN (use medication) then model components in the intake documentation
  • #20610: DeviceProfile: ADD LINK
    • Add Do not perform and reason code to deviceRequest
    • Add not done to deviceUseStatement
      • Lloyd states, this should be a status instead; this is needed in both R3 and R4:
        • in R4 medicationStatement in R4 it has not done as status;
        • in R3 had to have extension
      • Measure is looking for if something was done, and need reason for when it was not done – this can be at 2 levels – at order or at fulfillment of the order.
      • Need to only know if something didn’t happen at time X and why
      • Does DeviceUseStatement have statusReason element? Not yet – so need to add that element, if we are using status
      • There are two levels of not done:
        • Not done = device was not implanted
        • Not doing = patient is not using walker = not taken
      • Device not functioning is different from this
      • Would you create a procedure resource if it was not performed – would cancel the request and give reason
      • Do we need a reason for both Do not perform and not done?
        • reason is the reason for the request and would not capture the reason for not doing the order in this element
        • Is that more applicable at the task level of the request?
      • Motion to find persuasive with mod:
        • Add “not done” status code to DeviceUseStatement.status
        • Add status.reason element with example binding to DeviceUseStatement
        • Defer discussion on deviceRequest
        • Dan Rutz, David Burgess, no further discussion, against: 0, abstain: 0, in favor: 24
  • Same joint session next WGM = YES

Q4 - FHIR-I/OO/InM/MnM

Tuesday May 7, 2019

Q1 - OO/HCD


  • FHIR Healthcare Product Recap
  • Device Maturity
  • 20661- Administration for Breast Milk , Infant formula and TPN for newborns

Q2 - OO/PHER/BR&R + Rx + FHIR-I + HCD

Chair: Lorraine Constable

Scribe: Riki Merrick

  • Agenda Review
  • BRR update:
    • IDMP wgm summary May 2019 (update after BRR and Pharmacy).pptx
      • We have no parallel resources for non-regulated products
      • These comes from ISO standard, those are legal names, IDMP support
      • These are just in the builds – will need to set up resource proposals – Rik Smithies will create those
      • Could RegulatedAuthorization overlap with other domains?
      • Yes, but we have no one to work on those use cases – anticipated push-back; this is authorization for drugs to marketing – will deal with it via ISO mapping
      • Definition pattern in CDS – we may consider to apply that to substanceDefinition – for deviceDefinition OO got some pushback
      • ClinicalUseIssue – a lot of discussion on definition for this resource – Pharmacy Q3 had discussion about this new name, but CDS pushed for combination of this; Pharmacy thinks these are different things – need to point out the boundary to adverseEvent
      • Ingredient – we have discussed this and agree that it is ok to be used in healthproduct; it points to substance (and use strength)
      • Compare the diagram to the healthcare product model
      • Have mapping between the blue, green and yellow classes to make sure attributes are names the same in all of them – will do the same for healthProduct once complete
    • OO:
      • HealthcareProduct work update
        • The healthcareProduct powerpoint will be translated into cloudEA
        • Things in orange don’t exists – we added nutrition intake on right as orange and
        • Also still need to identify substanceDefintion
        • solid line = relationship exists, dotted line think there should be a relationship
        • bright green resources are owned by OO
        • light green exist, but need some additional work / merging?
        • Attempt here is to clarify boundaries in this
        • supplyRequest and relationship to deviceRequest and MedicationRequest
        • SupplyRequest: move things from one place to another – generic; for some situations should allow patient?
        • Still need to discuss: specimen event tracking and how would that fit in with this?
        • Next dealing with DeviceRequest and how that relates to supplyRequest
        • supplyRequest is ONLY for non-patient specific
        • SubstanceDefinition needs to have relationship to substance
        • BiologicalDevriedProduct – get some input on the substance part and biologically derived products, in particular how IDMP addresses (definitional) the concepts based on ISO 11238:2018 standard, as implemented by ISO/TS 19844:2018.= belongs to substance per IDMP; IDMP has definitions on how substance is related to medication – still need to evaluate the biologicallyDerivedProduct as next step
        • Would you use supply request on the biologicallyDerivedProduct?
          • Looking at matching, which is different from supply, though once match has been make, may be needed to move the product to the patient location – this is still open item – needs input from Bob Milius et al
        • Grahame is looking at abstract base classes (healthCareProduct could become a pattern or a base class)
        • BiologicallyDerivedProduct for fluid and biologicalAgent = these are instances – can move bloodbags for example – supply request could apply
        • Kinds of biologicallyDerivedProduct may also be needed to ordered;
        • Need to have boundary description when a blood in gene bank is specimen vs biologicallyDerivedProduct
        • Substance describes active ingredients
        • Need to have joint calls to discuss relationships between BiologicallyDerivedProduct / specimen /
          • BRR call is Tue 10 – 11 AM ET
          • Monday HealthCareProduct call is 3 -4 PM EDT (short term will be focused on device and )
        • Need to move device to FMM3 by next ballot, that will be the focus on Monday’s call
        • Related resources also need to become solidified, so device can be locked down
        • Supply is ONLY inside organization; across all HL7 products – between organizations should be covered by GS1 – if there is a new group that wants to work on that, would be new effort
      • Nutrition update:
        • Calls are Fridays 2 – 3 PM
        • Focus is NutritionIntakeStatement
        • Profile and IG for nutritionOrder
        • Will be use case for outpatient setting
        • Long term plan is to be able to capture specific food items, potentially down to nutrient level
        • Nutritional Functional Model
          • EMCPRS – need to get description – EHR WG was balloted in second round last fall, published without comments – Jean and Lorraine working on validation comments – actively seeking folks working separately on validation of the model
        • 20661- Administration for Breast Milk , Infant formula and TPN for newborns
          • How to represent TPN and breastmilk in FHIR – related to dealing with ingredients
          • Joint Commission quality measure is exclusively breastmilk intake; TPN should really be medication or procedure – that is how it is represented in SNOMED CT; would be a procedure performed – but it is most often documented as a medication administration; TPN are complex mixtures and defined by their components – maybe find type of TPN; it is ordered as a medicationRequest
          • If TPN= not in the population for the measure
          • If formula administered, then fail measure – this would be clarified by nutritionIntake work
          • Question: food is provided to a person – we need to know what substance caused the adverse event; would need to know the ingredients of the food
          • IDMP has worked on mapping for ingredients in DSRS project– DSRS = implementation of IDMP at substance level from manufacturing process - -at level of substance structure
          • Getting concept of structured product label into ??? ask Lorraine
          • Becky or Lisa to write up the baby related use cases (breast milk and milk formula = substance code in SCT) and send to Panagiotis, so he can add in mapping details; TNP is compounded patient specific substances that are administered a specific way, hence it is modeled as a procedure – use case was written up here: https://confluence.hl7.org/display/OO/Healthcare+Product?focusedCommentId=51221675#comment-51221675
          • This has 2 parts:
          • Representing the underlying data in the EHR-S – that is where we are right now
          • How is the quality measure expressed should be discussed in CQI.
        • Should we keep the joint next WGM? Yes for Pharmacy, BRR – Ulrike Merrick to check with PH
        • Adjourned 12:14 PM EDT

Q3 - OO

Chair: Hans Buitendijk

Scibe: Hans Buitendijk, Riki Merrick

  • Motion to accept updated PSS (PSS for Payer Data Exchange (PDex) (Updated)).  Lorraine Constable, JD Nolen
    • Against: 0; Abstain: 0; In Favor: 5
  • ASD - Looking for representative to US Realm Committee.
    • Hans is currently ad hoc member, but willing to take that up, if no one else steps up
    • US realm meets once a week and 1 Q at WGM, looking to become more steering than PSS review
  • Metrics
  • ProjectInsight
  • SWOT
  • NIB for September - Deadline: June 30
    • LIVD
  • Projects for January - PMO Deadline: May 24; TSC approval deadline August 16
  • Update Call Center to allow for OO to have duplicative calls - David Burgess 
  • Need to re-schedule all calls - Ulrike Merrick 
  • Meeting Room Request by May 17 - Hans Buitendijk 
  • Create September Agenda - Lorraine Constable 
  • OO-FHIR-I FHIR Planning either Wednesday Q4 or Thursday Q2
  • Expired STUs
    • Re-ballot, extension, or withdraw and Informative.
    • HL7 EHR-S Implementation Guide: S&I Framework Laboratory Results Interface (LRI) Functional Requirements, Release 1 (PI ID: 1095)
      • What is the path to informative.  Lorraine explore.
      • Consider STU Update to sync with  LRI STU1 R3.  

    • HL7 FHIR® Implementation Guide: Structured Data Capture (SDC), Release 1 (PI ID: 1104)
      • Needs to be transferred to FHIR-I - Riki to ask Lynn
    • HL7 Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1 STU Release 3 - US Realm (PI ID: 922)
      • Request all priors to LOI STU1 R3 are superceded - Riki check with Lynn.
    • HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface (LRI), Release 1 STU Release 4 - US Realm (PI ID: 1294)

      • The above reference to Release 4 is incorrect, should be Release 3.  It is correct on the website.
      • Request all priors to LRI STU1 R3 are superceded - Riki check with Lynn.
    • HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS), R2, STU Release 3 - US Realm (PI ID: 973)
      • Request all priors to eDOS STU2 R3 are superceded - Riki check with Lynn.
    • HL7 Version 3 Domain Analysis Model: Laboratory Orders, Release 1 (587)

      • Request change to Informative. - Lorraine
    • HL7 Version 3 Specification: Ordering Service Interface, Release 1 (PI ID: 1010)
      • have been waiting on feedback from OMG side and catalog is in this project, not sure if the OMG project will finish- this came up in SOA
      • Request change to Informative. - Lorraine and check with SOA whether acceptable.
    • HL7 Version 3 Standard: Care Provision; Food and Medication Preferences, Release 1 (1009)
      • If we can extend, otherwise change to Informative - Lorraine
    • HL7 Version 3 Standard: Orders; Diet and Nutrition, Release 1 (PI ID: 902)
      • If we can extend, otherwise change to Informative - Lorraine
      • Need to remove the duplicate entry in Expired STUs - Riki
  • Idle Ballots
  • Non-Advancing Ballots
  • Project Insight
    • #1339 - Why listed in HL7 Project Database for OO.  
    • #682 - Specimen CMET Relesase 2: Motion to archive.  Lorraine, Riki.
      • Against: 0; Abstain: 0; In Favor: 5
    • #1068 - LabOrder Logical Specification: Change next milestone to May 2020
    • #1335 - LIVD: Change next milestone to May 2020
    • All other Next milestone dates are Jan 2020 or later – so leave

V2.9 Ballot Reconciliation

  • Motion to let editors fix A-Ts.  Lorraine Constable, JD Nolen
    • Against: 0; Abstain: 0; In Favor: 5

Q4 - OO/II

Chair: Hans Buitendijk?

Scribe: Hans Buitendijk?

Media/etc.

Four topics:

  • Media/Doc Ref/Attachment
  • Clinical Notes relations
  • Observaiton/Value Attachment
  • Diagnostic Report

Link to Use Cases: Workspace for Attachment/Media Use Cases


Motion to prepare a target specification of DocumentReference (at the same time test the waters of new name) and updated Attachment data type, add DocumentReference where Media is referenced as a choice, to allow for prototype/connectathon.  Finalize decision by mid-June. John, David

Discussion

  • Not touching Observation or DiagnosticReport, but one may still consider how it may impact, but focus on DocumentReference and Attachment.
  • Need to get MnM to draft updated attachment data type.
  • All done in a branch.
  • Wherever Media is referenced, 

Against: 0; Abstain: 0; In Favor: 16


Observation.valueAttachment discussion can happen immediately.

DiagnosticReport/Composition

DiagnosticReport/ClinicalNotes


Wednesday May 8, 2019

Q0 - OO

Chair: Hans Buitendijk

Scribe: Riki Merrick

  • Migration of the publication model to EA on the cloud: Hans Buitendijk ADD LINK
    • This model anticipates to appropriate reader flow, but does not have to be that way
    • Building blocks stack on left – domain stack on the left
      • Connection between the stacks is the message structure
    • Datatype is linked to attribute table or the field definition, not both / need to figure out how to
    • Represent that
    • Not yet using the formalism of modeling, just dropping al the boxes in
  • Frank’s updates
    • How to use the component resource to maintain the data
    • Think we should use FHIR to store the source of truth
    • How to split into smaller chunks
    • FHIR structures to use:
      • Compositon for the combination
      • datatype
    • storing information of word document chapters as section, but it violates the current definition – so we need more steps to adjust
    • Also having a hard time to extract from the word document into the desired structures per the model
      • intent is to maintain a complete section containing ONLY text with html encoding and some diff elements around it
      • same should apply to tables and bulleted list
      • highest section with nested section
      • can use title and text and 2 more attributes:
        • coding – used to annotate the word style like capture, title, link etc.
        • segment should be a separate composition resource – so then you need a reference to the other composition? Or documentRef?
        • Section is repeating – it is NOT ordered, but can point to whatever you need
        • We could use backbone elements, BUT the problem is that these need to be unique
        • Message structure definition – FHIRpath is having the same issue – message structure is set of segments and message group; we need to introduce the choice – for example in merge message have 2 PID segments – then we can create 2 groups to make these unique
        • Similar issue with the entry in the composition
      • Discussion options:
        • Media and attachments will be merged and then we still have docReference – we could use that
        • Also discussion on how to handle diagnosticReport / composition / clinicalNotes
        • What about using bundle?
        • This might be doable, but
      • Right now our sections have a lot of nesting, that is not what composition is expecting
      • In order to use the composition the way it is currently made, we have to use multiple compositions and combine those
      • Have looked into using IG publisher
        • Using excel tables for input and the program takes it from there (hyperlink in html is backbone element in FHIR) – hard to have hyperlink to a set of words within a cell in excel – that is the same issue in composition but that is one of the main problem we need to get fixed to be able to do this
        • Can migrate the technical editing to FHIR resources (structureDefinition)
      • NIST tooling update – Mike’s slides
        • Have Mike go through these on the next call
      • Next call 5/17

Q1 - OO + HCD

Chair: Hans Buitendijk

Scribe: Hans Buitendijk

  • Observation.valueAttachment
    • Questions
      • Should a blob result be in .result(Observation.value), in .PresentedForm or in both.
      • What is the code and value type in an Observation when sometimes it is fully structured and sometimes blobbed.
    • .representedForm represents the combination of all .results.
    • If there is only one .result, does there need to be a presentedForm?
      • If a single sodium is ordered and reported, it would be in .result and should not require a .representedForm.  There may be a nice letter to embed that, but that may be it.
      • But if the observation has a blob, then some would like it to be in representedForm as well or instead.
      • The .representedForm could point back to the .result to avoid duplication/size increase.
    • Do we need some metadata on the observation ot indicate it includes a valueAttachment to avoid having to discover that and make it easier discoverable.
    • Also, one effectively creates the observation first, then the diagnostic report, so for some observations have to skip that.
    • What if we have add Observation.presentedForm?
    • Does it solve the scan of a CBC?  Can we distinguish between scans where the underlying 
    • Will ponder, and revisit with 

Q2 - II/CG + BR&R

Chair: JD Nolen

Scribe: Riki Merrick

  • CDISC lab – people not present, so not discussed
  • CG Update
    • Ballot reconciliation for IG for genomic reporting
      • Got through all ballot related items, additional trackers to completed
      • Should be published as STU by summer
    • Information modeling subgroup gave update = Global Alliance for Global health alignment on standards and API
    • Questions:
      • Cardinality of specimen in observation – create extension for additional specimen – is that just for IG, or should we make a core extension = should just be 0..* - will work together
      • Workflow question:
        • code and qualified by observation.component – how would I do a serviceRequest to mimick that, since we don’t have component in that?
          • Would it matter for ordering or is the order at the high level?
          • Some organizations require the genetic testing as a genetic consult
          • Organization has contract labs that ananomyzed specimen are sent to, where HLA lab testing is specific for the HLA types needed – could use the AOE approach for that – similar to fasting status of patient
          • Often use local code in service request that could group the expected components (usually not assign LOINC there, since that would create combinatory explosion)
        • zulip chat (CAN SOMEONE ADD LINK TO IT?): The need of free-text can we have sections – right now the diagnosticReport only supports one section
          • idea to use a FHIR document – how to handle that?
          • this fits into the discussion about diagnosticReport vs composition – may be allow DiagnosticReport to point to reference to observation OR composition
            • you can also use textual observations, if you just want textual observations – but if you need sections, then would use composition?
          • Nesting diagnosticReports? – not a good idea
          • What is the value of both diagnosticReport vs composition? – or could diagnosticReport be more generalized?
          • Need to also define better boundary to clinicalNotes
          • It would be hard to search for composition types, if we get rid of diagonsticReport
          • Keep the business object of answer to a ServiceRequest as a distinct object
          • We lost 1:1 relationships, when we merged DiagnosticRequest and ProcedureRequest into ServiceRequest
          • In the Lab order model we have this workflow:
            • Request
            • promise on order
            • result
            • report of all results
          • Talked about building this in FHIR based on that model – currently have no resources for that
        • What is the level of abstraction between observation and diagnosticReport:
          • What if the report (paper) has only 1 result vs multiple results
        • NEXT STEPS:
          • Need to deal with diagnosticReport vs composition - do that on the specimen call Tuesday 3 – 4 PM EDT on the alternating weeks
            • We have a pair of use cases:
              • Results on a patient that comes in as paper version of data
              • Transplant related results – both discrete, paper and narrative
            • Goal for R5 is to get DiagnosticReport into normative FMM
              • Structure of DiagnosticReport, besides the section handling and how we deal with micro and anatomic pathology
            • Micro question around organism with susceptibility testing:
              • Option 1: use observation.hasMember, and each susceptibility test is a member
              • Option 2: Use observation.component for the specific organism result (since some properties are inherited from the observation – like test date, which can be different
              • Option 3: Use observation.focus and make the organism this susceptibility observation is about
            • Need to solidify the specimen resources in the next cycle to support genomic testing and anatomic pathology and digital pathology = do that on the specimen call Tuesday 3 – 4 PM EDT
  • Update from Q4 yesterday about boundary on observation – documentReference – media
    • We set up use cases to look at the different approaches to address these
    • Favorite approach was merge of documentReference and media (move the scope to documentReference) and add the media specific attributes to the attachment datatype (need to check with MnM) – and then apply the new resource to the collected use cases
    • Folks want to do observation. value attachments – separate issue
    • Give documentReference a new name (indexedContent? / registryEntry?)
    • Who will work on this – goal is media will go away
    • Adding new optional elements to something that is normative is backwards compatible, so should be doable
  • BR&R Question:
    • Pharmaceutical quality is using batch reports – FMG likes people to use existing resources, so want to use observation
    • How to use observation.code and observation.status in this use code
    • We don’t use LOINC codes and have different codes – binding for LOINC is example only
    • Subject would be a lot of pharmaceutical – will need to add to that list; MedicationKnowledge or MedicinalProduct and Medication
    • HealthCareProduct call is Monday 3 – 4 PM EDT
    • Boundary between non-clinical observations and measure (owned by CQI, CDS)
    • When you make a drug:
    • Can test substance of the production – specimen is here medication, which can have one or more ingredients (test the API) testing the device and the content – dose uniformity, - tracker item that specimen needs to address this use case – need to add medication as allowable subject
    • May need to look at medication to see, if it has everything
    • method – is codeable concept; in clinical genomics is often a narrative text; it has to be conveyed with the result, so for now use the text component
    • Do we need to be able to reference procedureDefinition
    • Or can we use annotation – if we extend annotation with annotation.type we could use the annotation for this type of note: idetifying the protocol used
  • II Update:
    • Is not dead – have a new co-chair now J
    • Were resource poor last cycle
    • Ballot recon on FHIRcast
    • Apply FHIR tracker items
    • imagingManifest (specific images that could be used across multiple studies) DICOM equivalent exists, so we removed this resource – but right after that folks came up with other use cases outside the image archiving (where DICOM is required), so bringing it back – also needed to support reference from observation to it, when result is related to a single image in a study
    • imagingStudy (complete DICOM study)
    • questions on how to capture radiology reports
    • How to capture informal communication between the tech to radiologist – pass notes i.e. tech wants to draw attention to the radiologist – is it a clinical note?
      • Not usually passed into the patient’s chart = could use communication – but that is a record of a communication, often part of the patient chart
      • could attach flag (http://build.fhir.org/flag.html) – persistent note that can be added to anything? via subject attribute (currently has a limited list, so would have to extend the allowed references)– similar to provider to provider communications - -do we need to add focus so we can have a report or an image as the focus, but still link to the patient as the subject?
      • This needs more discussion!
  • OO Update:
    • Specimen DAM publication request has been submitted
    • Will be working on specimen
  • Keep quarter the same for September WGM = Riki will check with BRR

Q3 - OO/FHIR-I/PC/CQI/CDS

Chair: JD Nolen PLEASE CONFIRM

Scribe: Riki Merrick

  • Agenda review
  • Question from II about project where II is co-sponsor:
    • #6??: SpecimenCMET – is archived
    • #1010: will try to find out how to drop this to informative, the project is active, as it also covers the catalog work; the SOA part of the work is stuck in OMG processes
    • #1343 – eyecare is on hold – will ask Lorraine; could compare to IHE work
    • #1453 – Still going
  • Nutrition Update
    • Friday calls 2 – 3 PM EDT – will be weekly
    • Collecting use cases
    • Create nutrition intake resource
      • Had presentation from Italian group who did extension on observation, they suggest new resource
      • Then may also need labeling for this – healthcareProduct related
    • Nutrition order to generalize to outpatient (is scoped to inpatient currently)
  • documentRef / Media - attachment datatype issue (see Q2 discussion above)
    • related to this, but separate: observation and inclusion of valueAttachment for observation.value,
    • boundaries for clincial notes – diagnosticReport - docRef
    • Current thinking:
      • Add media attributes to attachment and remove media and separate docRef –
      • Do we need name change for docRef (decision in June after walking through the use cases)?
        • For consideration: What is the ROI for changing the name, as it is a cost for implementers to do that; concern was the current name discourages its use of docRef for other uses that are not usually thought of as documents
        • Implementers reading the spec may get it, if they read the scope, but for the group here may
        • Effectively have that resource become a more structural resources – the content should live elsewhere, and this provides indexing / metadata about the content – then challenging how to model clinical notes, document really that could be any kind of file, really, but here we have the problem that “document” has a different notion;
        • it seems the definition has changed, and so that a name change seems appropriate – ask IHE implementers of MHE and the Australian government, where it is in production
        • OO thinks to test the waters first before name change decision
      • SD recommends to add a reference to any resource in attachment rather than just a URL – want to make a tracker item after discussion with MnM and OO:
      • Rationale for documentReference to go to OO, rather somewhere else – it is about any type of media, so should go to OO
      • Update from SD:
        • From SD minutes : https://confluence.hl7.org/display/SD/SD+WGM+May+%2719+Tue+Q1+Minutes+Host+FHIR-I
          • Proposal: SD requests that OO merge DocumentReference with Media and discuss that the new name be "ContentReference" and add to content a reference to Any resource; transfer ownership to OO
        • Next steps:
          • Email about adding optional elements to attachment datatype – is owned by MnM not FHIR-I
        • Clarification: Scope from media is moving into documentReference and attributes from media move to attachment datatype
  • DiagnosticReport
    • Issue is that current resource has ONLY 1 section with a single narrative description:
    • Example in radiology reports , AP, clin genomics – sections need to be named and placed in a particular order sorting sections of text along with discrete data as results
    • Discrete results, findings, methods, impressions – often modeled in CDA – so folks consider composition, but not currently part of
    • Can we add reference to composition to the DiagnosticReport?
    • FHIR-I and OO – there is a C-CDA on FHIR guide IG profile – ADD LINK; was published last year, but not implemented / tested
    • Currently have findings DICOM object catalog, DIR section – could add slices for the other kind of common sections there
    • Itemize ALL options – and walk a use case through all of them for evaluation
      • Could create standard extensions on DiagnosticReport
      • ADD THE OTHER OPTIONS HERE!!!!
    • The current DiagnosticReport was expecting to represent each section an observation
    • On CG side there may be testing that might have to be handled as DiagnosticReports – so may need to have nested diagnosticReports
    • If there is a significance to the order of the sections, for example what the doc should see first – that cannot be done with list of observation;
      • In v2 we currently don’t customize the order of the OBX segments, but folks often don’t do it
      • In LRI in v2 we made it explicit by supporting grouping and sequencing or using the dot notation per CG profile to determine the order of the observations – do something similar
  • NEW topics:
    • Output of an observation is a complex csv file – cannot really be modeled by observation.value
      • Sleep study – the video recording is an entity that we need to have (clinically relevant), which can result in observations on it
      • In lab: Chromosome testing, there is a block of information that is too complex to render it in a discrete manner, so send as
      • Should we bring valueAttachment back into observation
      • Or should there be presentedForm of observation and how to pick the right LOINC for that – but hard to use for data retrieval
      • Have the lab result that is ONLY a pdf – where should those go?
      • Also need to have consistency for data retrieval for both discrete data / blob data of a particular type, regardless of the number of results contained in it
      • Where does the “blob” go?
        • when is it a valueAttachment
        • when does it go into documentReference – need to align the use cases to come up with a consistent approach
      • In Australia have used presentedForm for observation as a reference to the copy of the “paper report”
      • Are there instances of how to deal with images that are used as basis for observation - could be treated as a virtual derived specimen, similar to the digital images of microscopy slides  (Whole slide imaging WSI);
      • Singular observation that is made with blob format – why would I take that blob and represent it as presentedForm in diagnosticRerport because in diagnosticReport presentedForm is defined as the ENTIRE collection of the results
      • There may be value in ensuring there is always a diagnosticReport as a wrapper, even if just one observation used?
    • Is there ALWAYS a diagnosticReport as an answer to the ServiceRequest?
      • Have some guidance in the resource page – need to review and update
      • In Australia we MUST have diagnosticReport around each observation, since they always also ??? MISSED SOMETHING
      • presentedForm can point to somewhere else – so can link to the observation in its own
      • DiagnosticReport has media attribute that references media resource – it is described as supporting image for the observation – that sounds more like imageManifest potentially
      • NEXT STEPS:
        • The piece about sections in diagnosticReport for Clin genomics and APSR will be on alternating specimen calls Tues 3 -4 PM EDT
        • OO on FHIR call Tues 2 -3 PM EDT can tackle the grouping and media / documentReference / attachment – schedule same time as the specimen call when sections are the topic, so we could use 2 hours
    • Bodysite and location must also be followed up on - maybe also on the specimen call?
      • CIMI was working on a profile on observation to represent bodysite, but we discouraged that
  • Same joint next quarter September WGM – add reps from II? YES

Q4 - OO

Chair: Hans Buitendijk

Scribe: Riki Merrick

  • V2.9 ballot reconciliation
  • Review all items if they are substantive and NOT part of the scope of ballot #4 – wil apply disposition of “not related”
  • Filter on Negs
  • Filter on Chapters 4A:
    • #5: Typos on change notes are not retained for publication, so no need to fix these, but will fix, if there is another round of ballot
    • #6: Across all of the document – punt to v2.9 – assigned to pubs already
    • #143 through #144 – check with Tony about how many versions from backwards compatibility till withdrawn – 2 Full versions – so if B in v2.7, then W in V2.9 = Motion to find persuasive JD Nolen, David Burgess, no further discussion, against: 0, abstain: 0, in favor: 5
  • Chapter 4:
    • #223 – Kathy Walsh in person: Related to ORC-7 – David B will take a stab at re-writing this text and review with Kathy
    • #229: Quantity/Timing – Motion to find persuasive Riki Merrick, David Burgess, no further discussion, against: 0, abstain: 0, in favor: 5
    • #229: Change the second ORC-9 to ORC-1 – Order Control code – persuasive with mod – Riki Merrick, JD Nolen, no further discussion, against: 0, abstain: 0, in favor: 5
    • #230: Proposed motion to change to: focuses on the date when the patient agreed to pay for potentially uninsured services – does this create a substantive change? Or we leave “gave consent” – technically this is out of scope of this ballot round.
    • #132, #133, #134, 135, 136, 137, 138, 139, 140, 141, 142, 124, 125, 126, 127, 128, 129, 130, 131, 123,  - same as #143 - #144 – apply the same vote here as well
  • Chapter 7:
    • #147: Same as #143: apply the same vote here
    • #148: this applies to ALL subsections of 7.2.5, as that is where the note about the backwards compatibility is – apply the removed text at that level: persuasive with mod - David Burgess, JD Nolen, no further discussion, against: 0, abstain: 0, in favor: 5
    • #149: Motion to find not persuasive, because we indicated that prior to publication we will replace the OBR section with OBR content from Chapter 4, as we wanted to avoid duplicative and potentially conflicting ballot comment resolutions – Riki Merrick, David Burgess, no further discussion, against: 0, abstain: 0, in favor: 5
  • Chapter 13:
    • #289: withdrawn by submitter – is duplicative to the deprecated style application
    • #182, 183, 184 - same as #143 - #144 – apply the same vote here as well
  • Completed review of all NEG (one outstanding), so all others, except A-T
    • #256: 4.4 on page 20 name of the group – the PRT and DEV are related to the OBR not the OBX: change name of this group from Observation_Participation_Prior_begin/end” to Order_Detail_Participation_Prior_begin/end – motion to find persuasive with mod David Burgess, Riki Merrick, no further discussion, against: 0, abstain: 0, in favor: 5
    • #208, #210, #213– relates to the re-write David is working on
    • #260: Motion to find persuasive Riki Merrick, JD Nolen, no further discussion, against: 0, abstain: 0, in favor: 5
    • #261:Motion to find persuasive Riki Merrick, Becky Gradl, no further discussion, against: 0, abstain: 0, in favor: 5
    • #215: Motion to find persuasive Riki Merrick, Becky Gradl, no further discussion, against: 0, abstain: 0, in favor: 5
    • #262 – same as #215
    • #206:  Motion to find persuasive Riki Merrick, JD Nolen, no further discussion, against: 0, abstain: 0, in favor: 5
    • #217: same as #206
    • #274: Motion to find persuasive Riki Merrick, JD Nolen, no further discussion, against: 0, abstain: 0, in favor: 5
  • Final spreadsheet:
  • https://confluence.hl7.org/download/attachments/4489770/ballotcomments_V29_R1_N5_2019MAY_amalgamated_Prepped.xls?version=1&modificationDate=1557348704703&api=v2

Thursday May 9, 2019

Q0 - OO - V2 to FHIR Mapping - Tooling

Chair: Hans Buitendijk

Scribe: Riki Merrick

  • V2-FHIR mapping
  • Slides: ADD LINK
  • Focus is on mapping definition:
  • Csv -> FHIR?, JSON, XML, mapping language
  • Creating an IG from the csv files = create html process for reading and also providing the same downloadable forms as any other IGs
    • Using csv is bothersome- where does the metadata come from (author, what, where, when etc) – this is currently in GitHub as a properties file; metadata content is text content – add to each csv file in additional columns
    • Create tabular representation of the csv file – this is the formal definition in the IG, the rest is derived material; include the loader of the csv in the IG publisher, then we don’t need the converter as separate tool
  • Republish the spreadsheet and any other content as additional resources
  • API: what would that look like? = this is NOT at runtime conversion – that is what the Apps would be doing outside of HL7
  • Mapping is currently conceptual mapping – how to deal with nested observations etc
  • Apps would have to deal with the complex issues and localization mapping – this would be the second part of the project; that can run in parallel – some folks are already working on that part – we do need a common API definition
  • We need 2 APIs:
  • Get the mapping material – we are using Github for development, and once we have the IG published, so use that for that part
  • Real-time runtime API for transformations – that is for apps to develop
  • Example content messages in v2
    • Right now we collect good messages, meta data – can Frank use some of these for use in the V2 publications – V2MG is talking about this
  • When you have a V2 IG can we create and include all the constraints of those in the converter – not in scope of this project- that will be part of the harder part
  • FHIR already has a converter operation – ADD LINK
  • Review Spreadsheet:
    • A tab per FHIR release – currently mapping to R4
    • From V2 side we have fixed content (starting after v2.5); for withdrawn elements – will have to provide a bit more information but mark the cardinality
    • Column descriptions
      • We added display sequence, so folks can reorder during work, but can be displayed in a particular order
      • Field element is used as key on V2 side
      • Condition IF True: what syntax do we use in this field is still open for improvement (maybe we can make that FHRpath directly – this could be a conversion later) -
      • When datatype is complex, need its own mapping, but for some datatypes the mapping location depends on which field uses this datatype
        • EVERY row must be executed in the spreadsheet – create rows for each condition, if there is more than one rule on it (use spreadsheet approach to document)
      • Have a column for derived mapping, so we know a lot of other things may need to be updated, if there are changes
      • Datatype mapping column supports subcomponents
    • For message mapping for some fields there is a datatype conversion (ID to Code or the other way around – will need to include valueset mappings
    • Amalgamate the existing mappings using the same format (and potentially use tooling to compare the content of different mappings using the same format) the mapping to be presented to the larger group for review and conflict resolution => create a subgroup for this work – using the tools call to figure out the process – will set up close timeline for deliverables – have the person responsible for the segment apply the subgroup decisions

Q1 - OO

Chair: Hans Buitendijk

Scribe: Riki Merrick

  • Attachment prototype setup
    • Keep DocumentReference – merge with media scope, maybe change name of this resource
    • Stop using media
      • Height
      • Width
      • Frames
      • Duration
      • Analysis between documentReference and media – missing 4 things that are specific to describing and image / video = optional attributes are:
    • Approach to dealing with decReference, media and attachment datatype
    • By June need to know what we want to do with these:
  • For discussion in MnM:
    • Normative datatype – but should be able to add optional elements – should this be a core extension (that could be a starting point)
    • This could mean more attributes could be added like size / pages for other types of attachments
        • Update attachment datatype with a few attributes from media  (MnM owns this)
        • Next MnM call is 5/14, should have answer by then
        • Can make the changes in the branch already as an extension
      • Regroup with OO on FHIR mid June
      • Feedback from MnM:
        • These elements can be core
        • Add consider adding number of pages
        • OR add just one repeating element that is code and quantity to accommodate these and future attributes
        • Hans will let John Moehrke know that he can build this (or maybe create 2 variations)
  • SET CR
    • Brief introduction to the SET profile 
    • Starting with Specimen movement messages
      • will re-arrange the message events to be in chronological order
      • idea here was to have these uni-directional
      • we will still rename the z part to proper event codes
      • acknowledgment choreography
        • assume accept level acknowledgement for some of these, but for some may need application level ACKs; this is still a TODO
        • since this is a simple notification / subscription do we even need an accept ACK? We would like to have at least the accept ACK
      • Why do we need to have separate message structures
        • We tried to have 2 methods to
        • Use MSH triggers for the general type of event
        • EVN-4 is more for business processes
        • Some of the use cases needed different data elements
      • Will stick these into the Chapter 13 section
      • Is similar to the SSU message, but EQU is required in that message
      • Specimen Reject message:
        • Is this partial rejection, or overall?
          • Message with 10 specimen moved may result in 5 messages with rejection and 5 with acceptance
          • Similar can do that in the package movement approach
          • Shipment Status = SHP-3
            • First segment in group cannot be optional, so reconsider placement of (Shipment ID and status date/time) is required – it is weird that the status is not required (Riki to ask Austin about that); include request to make status required in the base going forward
              • Status vocab may need some review
                • Harmonization may be needed (later)
              • If some of the specimen are accepted and some rejected, what would the status be: probably need to look at the
              • What about making the shipment either accept (= inventoried) or reject and then follow up with accept / reject messages at the separate specimen level
              • May need to look at X-12, since shipping industry uses that – may need to map / properly represent the data element
            • Review the levels rejection can happen:
              • Shipment
              • specimen
              • container
            • PRT-7 use of this seems incorrect:
              • SHP segment does not have a good place for FromEntity and ToEntity for
                • PRT-4 will need to be populated for sure – so we need to update the vocabulary for this field => harmonization proposal!
                  • PRT-8 or PRT-5 are options
                  • PRT-7 is just a classification of the organization type (like home office etc.)
                • Other option would be to extend the SHP to have the ToEntity and FromEntity
                • Same applies to the package centric structure, but in addition: can there be a package in a package?
                  • PAC-3 is the parent package ID
                    • If we want to allow it, we will need to describe it – bring back to the IHE committee!
                  • Specimen Identification tracking
                    • Will apply the same solution of PRT above – may also require more codes for the harmonization proposal
                    • Z13 – z17 have the same message structure, but the document is organized by use case – so we will end up with NEW trigger codes, but re-use of the same
                    • Pull the description of re-identified (applies to any point in time, when a new identifier is assigned to a specimen) and de-identified (applies ONLY for biobanking use case) message use case from the profile for more context for reviewers – make this e.g. a biobank (vs it could be a trusted entity))
                    • Do we need different messages for re-identification and de-identification – we need to have the business action defined as being different - We have 3 mechanisms in v2:
                      • Trigger event (like we use in ADT)
                      • Action codes (like we use in ORC)
                      • EVN segment
                    • We could accommodate the de-identification when we are using first a delete and then an add rather than the new trigger code of de-identification
                  • NEXT STEPS:
                    • Bring this back to IHE PaLM at F2F
                    • Bring that back after that for WG level approval – and harmonization proposals – mid June for group review
                  • Agenda update:
                    • Q2 – no real topics here – suggest to attend charge discussion in PA
                    • Q3 is V2 to FHIR mapping
                    • No meeting today Q4
                    • Will decide what to do about Friday Q1 in Q3 today

Q2 - OO

No topics - OO participated in PA quarter

Q3 - OO

Chair: Hans

Scribe:

Agenda

  • v2 - to - FHIR  with PA

v2-to-FHIR

  • We reviewed the general approach to review process for mappings.
    • We would prep a segment, then send it out for initial review in the project team, and resolve as much as we can where there are variant proposals to map.
    • We will use the workgroups for specific topics that need their decision where a choice needs to be made that was otherwise not resolved.
    • Workgroups will also be used to request extensions.
  • We reviewed the latest work in progress on mapping PID to FHIR Patient.
  • PID-2.2 - Check Digit and PID-2.3 - Check Digit Scheme
    • We will be suggesting extensions to capture these components.
  • HD data type
    • This is a challenging discussion.
    • Australia defined extensions and we concluded we should pursue extensions as well for universal ID and universal ID type.  They should be defined generally so we can re-use them where it does not make sense to reference an Organization resource, unless that is otherwise already in play.

Q4 - OO

No Meeting 

Friday May 10, 2019

Q1 - OO

No Meeting

  • No labels