- Want to rename the Schedule datatype, is that ok with core team?
- Are our resource proposals we sent to FMG in May acceptable? Where can we find feedback?
- When is the QA period for DSTU2?
- PA has finished making a ServiceDeliveryLocation profile on Location
- What is balloted in May? Leftovers from the january ballot? Can we still do major changes after january WGM?
- Is the order of entries in List retained? Do implementations guarantee this does not get lost? Is this a patient security risk? Do we need to add a specific order element to the things contained on the list to be absolutely sure?
- Does the current Observation scope have any narrative that makes it impossible for us to "legally" profile it to become a DeviceObservation? Are there any elements on Observation that hint that it is for clinical Observations only? Who will correct this if this is the case?
- Goal: Coordination of activities done by the committees around PDQm, MHD(i) and PCD. IHE workgroup will not do this work, remains with the people in the workgroups who are both in IHE and HL7.
- Goal: Will take on tracker items for DocumentReference, SecurityEvent, DocumentManifest
- Group will be renamed from IHE to......(Healthcare Standards Integration?)
- Will FHIR be present at the IHE Hackathon in Cleveland after the HL7 WGM?
- SOA & ITS will cooperate to consider the issues raised by the current Service Page in the spec.
- Q: What is the current pattern in FHIR to do decision support using FHIR?
A: Define and Use specific service functions in FHIR? How to communicate workflow state if that requires different data than can be represented using resources? - Contact Claude Nanjo to see whether the FHIR spec can be used/is compatible with/can provide input for the OMG RfP for PubSub, Order and Universal Communication
- Do Order workflow / PubSub as a topic in september 2015 connectathon?
- Turn xml comments into a specific property in json so it can be round tripped but also retained in the examples and when documenting messages sent to other systems
- Can we somehow turn the current HTML "processing instructions" for the build-tool into real XML processing instructions (or look at how AngularJS puts macro instructions into the xml markup), so the HTML input files become valid XML
- We can split off generation of HTML for Profile and ValueSet from the full spec generator, if the spec generator outputs a file with links to the core artifacts, so the HTML generator can generate the correct links
- Will define a directory structure + .ini/config file as input for a Profile website generation tool. Output looks like the site currently generated for HSPC (no public link available ;-)
- Do ("open"?) slices still contain the original "base" definition of extension (0..* "extension" elements of type Extension), so validators can still know what can go into the open slots? Where to repeat the original definition in open slices (beginning,end of slices list)? Do we need to specify "open" if we explicitly add the base definition? A The original definition of the slice goes into children of the slice entry.
- The DSTU2 profile has an “Observation.valueQuantity” in the element path. Shouldn’t that remain “Observation.value[x]”, I am pretty sure we discussed slicing Observation.value[x] on “type” to do this kind of thing. If so, why does the base spec not do this e.g. for Profile.Binding.valueset[Uri/Reference]? This way you can express the two xpath constraints about the “http” prefix correctly. What’s the difference between a Observation.value[x] with one TypeRef? Why does Observation.applies[x] remain unchanged in the profile? A The path should remain Observation.value[x], where there's (in this case) just a single TypeRef
- Can we have TypeRefs + nested constraints….so the full set is TypeRef AND nested constraints
- Reuse xpath constraints across resources/datatypes A We cannot support this yet
- Generation of "primitive" structures (allow expansion when constraining extensions in primitive elements) A This will be added to the base profiles in validation.zip
- Can fix to complex types, not only to primitives? A Yes, in DSTU2 we can fix to complex types. Need to clearly define what "equality" means when comparing an instance value with a fixed value in the profile. Probably add this method to the ref implementations
- How to reference to slices when slicing a derived profile A We'll follow the dotted notation as used in openEHR archetypes
- Apply corrections to validation.zip for bugs found in DSTU1 to produce correct DSTU2 validation.zip A EK will provide input to GG
- Naming of the top-level elements: I am using “lipidPanel” (notice the lower case), and your example uses “LipidProfile”. The casing is a matter of taste, but calling a structure a “Profile” is confusing in an example.
- Do we need to repeat the search params in the snapshot profile?