FHIR Chat · find-variant Operation · genomics/committers

Stream: genomics/committers

Topic: find-variant Operation

Kevin Power (Jan 13 2020 at 23:30):

Starting a new topic for the Operations branch of work.

@Bob Dolin - Looks like you have been tweaking a lot today, I like the progress. I will note that you can do the build locally (by running the "_genUpdatePublisher" script that is appropriate for your OS), the opening the output folder, and loading "operations.html" page in a browser to view your changes.

Bob Dolin (Jan 13 2020 at 23:33):

@Kevin Power Let me add that to the list of things I haven't figured out how to do... ;-). I just get a 'BUILD FAILED' when I run _genUpdatePublisher.

Bob Dolin (Jan 13 2020 at 23:34):

If it's too annoying seeing all the traffic on committers/notification, let me know and I'll figure it out

Kevin Power (Jan 13 2020 at 23:35):

Can you paste the build log you get locally (just copy/paste your terminal screen text after the build fails)?

Bob Dolin (Jan 13 2020 at 23:39):

will do. In the meantime, here's where I am with the page, and the current issues that are stumping me:

Bob Dolin (Jan 13 2020 at 23:39):

[1] I can't seem to change the position of 'Find variants' in the Table of Contents. How does one determine the ToC sort order, or deliberately move an item elsewhere in the list?

[2] On the artifacts page, where would you enter in a revised description of the operation? I changed the description in the IG (resource.description), but that didn't seem to do it.

[3] On the operations page (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/operations.html), I can't figure out how to insert a line break after the image, so that section 3.1 starts on a fresh line.

[4] For the description of the find-variant operations (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html), I can't figure out how to place an intro or a notes page, so that I can include introductory and footer text, respectively.

Bob Dolin (Jan 13 2020 at 23:42):

And here is the build log from my attempt at a local build:

Bob Dolin (Jan 13 2020 at 23:42):

build.log

Kevin Power (Jan 13 2020 at 23:45):

re: the build error, you have to install some extra stuff. See the list here: https://confluence.hl7.org/display/FHIR/IG+Publisher+Documentation#IGPublisherDocumentation-Installing (for Windows it looks like you are using)

Kevin Power (Jan 13 2020 at 23:45):

This was the key part of the log:

 [java] Generating Summary Outputs                                                       (01:30.0416)
 [java] Sending Usage Stats to Server                                                    (01:41.0672)
 [java] Jekyll: 'jekyll' is not recognized as an internal or external command,           (01:42.0131)
 [java] Jekyll: operable program or batch file.                                          (01:42.0131)

Kevin Power (Jan 13 2020 at 23:56):

RE: other items

[1] - I am not sure about the ordering of things in the TOC, but would assume it is based on the order of the Resources in the IG?
[2] - It should be the resource.description - I made a change and it seems to update after I build?
[3] - I fixed that and will push to GitHub shortly.
[4] - I am not sure either

Bob Dolin (Jan 14 2020 at 00:19):

@Lloyd McKenzie Can you help with a question? It looks like the publisher supports including a header and footer to the operation (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html), but I can't seem to figure out how to do it. The referenced operation is 'src/resources/operationdefinition-find-variants.xml'. I've tried inserting 'operationdefinition-find-variants-intro.xml' into src/pagecontent and src/resources, but no luck. Can you advise?

Lloyd McKenzie (Jan 14 2020 at 00:21):

Try OperationDefinition-find-variants-intro.xml

Jamie Jones (Jan 14 2020 at 00:25):

There is header/footer content for Variant, you should be able to follow that pattern

Kevin Power (Jan 14 2020 at 00:29):

What folder do those extra files for intro belong?

Bob Dolin (Jan 14 2020 at 00:37):

I think pagecontent - let's see what happens with this build...

Bob Dolin (Jan 14 2020 at 00:44):

Ok, it worked (whew, finally, something...) the operation is here: src/resources/operationdefinition-find-variants.xml; and when it renders, it is automatically picking up this header (src/pagecontent/find-variants-intro.xml) and this footer (src/pagecontent/find-variants-notes.xml)

Lloyd McKenzie (Jan 14 2020 at 01:26):

Ah, because you're still using the old template. Once you migrate, you'll need to tack OperationDefinition- on to the front. (No hurry to migrate - a few more changes to commit before I start poking people.)

Kevin Power (Jan 14 2020 at 15:40):

@Bob Dolin - I think we had talked about the return being a Bundle of Observations rather than a DiagnosticReport. Any more thoughts on that?

Jamie Jones (Jan 14 2020 at 15:41):

Ideally it should come with a provenance resource as well, in my opinion

Jamie Jones (Jan 14 2020 at 15:42):

Anytime we are creating Observations with an algorithm we should push for versioned representation of the computation

Jamie Jones (Jan 14 2020 at 15:44):

If there is a report then we could get around that maybe, by including that information in the report's fields

Kevin Power (Jan 14 2020 at 15:44):

Seems we would need a profile or at least guidance to describe what that would look like?

Jamie Jones (Jan 14 2020 at 15:45):

Is there guidance on performer, etc for the DR? The report won't have been created by the original lab

Jamie Jones (Jan 14 2020 at 15:45):

That may be cleanest

Kevin Power (Jan 14 2020 at 15:49):

I am not a fan of using DR, as I think it could be confused with a "real" report. But, the 'performer' as an example has pretty generic guidance: http://build.fhir.org/diagnosticreport-definitions.html#DiagnosticReport.performer

Kevin Power (Jan 14 2020 at 15:52):

But I still think a Bundle with a type = collection makes the most sense in this case:
collection Collection The bundle is a set of resources collected into a single package for ease of distribution that imposes no processing obligations or behavioral rules beyond persistence.

Bob Dolin (Jan 14 2020 at 15:54):

Hi @Kevin Power . I'm still in the process of making the pages look pretty, and then plan to return to the outstanding comments that are on the google sheet. In the latest incarnation (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html), the response is a bundle.

Bob Dolin (Jan 14 2020 at 15:57):

Rationale for including DR was based on assumption that folks would having growing comfort with the IG, and would find the DR more intuitive than some other bundle of objects.

Bob Dolin (Jan 14 2020 at 16:00):

I'm kinda anticipating additional operations that provide annotation services (e.g. include implications), and was thinking that those would also follow the IG.

Kevin Power (Jan 14 2020 at 16:00):

Now that I review the OperationDefinition a bit more, perhaps we should describe it as different Out parameters? 1..1 RegionStudied, 0..* Variants, and 0..* SeqPhaseReltns? And if need, 0..1 or 1..1 Provenance?

Bob Dolin (Jan 14 2020 at 16:02):

ahhh, I like that idea.

Bob Dolin (Jan 14 2020 at 16:03):

Do we also need to define a 1..1 Bundle as a return parameter, or is that just implicit?

Kevin Power (Jan 14 2020 at 16:21):

If we do things as OUT parameters, we would not need a Bundle. Just define different OUT parameters (one for each type of thing we would return), and they would be returned in the "Parameters" resource.

I did find this example that is sort of similar to what we are doing, and they did define a single OUT parameter as a Bundle:
http://build.fhir.org/group-operation-everything.html

That might be because enumerating all the kinds of things that could be returned is not possible in that case. But in our case, we are OK in limiting the kinds of thing returned.

Bob Dolin (Jan 14 2020 at 17:40):

Not sure I really know all the pros and cons when weighing DR or not, Bundle vs. Parameters, +/- Provenance, etc. For now, I'll revise the page to have a DR as part of a bundle, and add OUT parameters per Kevin's suggestion, and I'll add in some examples, and then we can start throwing stones at it.

Kevin Power (Jan 14 2020 at 17:56):

For now, I'll revise the page to have a DR as part of a bundle ....

I was suggesting bundle INSTEAD OF a DR, not in addition too? Unless you are saying we would also return any DRs associated to the Observations we are returning?

Bob Dolin (Jan 14 2020 at 18:04):

oh, I thought the addition of the DR might help tie everything together, package everything up in a way that folks find intuitive (because they understand the IG). Here's an example (although I'm not wedded to keeping the DR, just showing you what I'd been thinking):

Bob Dolin (Jan 14 2020 at 18:04):

find-variants_response.fhir.json

Bob Dolin (Jan 14 2020 at 19:18):

@Lloyd McKenzie Wondering if you can help with another question? I'm trying to indicate that the operation response needs to include instances of several different profiles (region-studied, variant, sequence-phase-relationship). OperationDefinition.outputProfile has cardinality of 0..1, so that doesn't seem to work. If I define OperationDefinition.parameter.type='canonical', I can point to the profile using OperationDefinition.parameter.targetProfile, but the target profile doesn't appear in the rendering. Any suggestions?

Lloyd McKenzie (Jan 14 2020 at 19:46):

What are you passing out in the Operation? If you're passing out a Bundle, then the profile you refer to needs to be a profile for the Bundle as a whole, not for individual entries. (The Bundle profile could enforce that a certain number of entries exist that comply with certain profiles).

Kevin Power (Jan 14 2020 at 20:06):

The DR still seems duplicative and potentially confusing to me - confusing in that will everyone expect it to be a 'real' DR that was produced by the lab, not a "virtual" one that is effectively bundling the results for you, inside the Bundle we are returning.

In a review of other operations, it seems fairly common for the return to be a Bundle, versus having multiple OUT parameters (which we could define as. I didn't see any that profiled Bundle, but maybe some do.

Bob Dolin (Jan 14 2020 at 20:16):

so if I'm understanding correctly, [1] I'll remove DR; [2] we'd only have a single OUT, which is a Bundle. For now, I can describe the constraints on the bundle, but ultimately, we'd want a profile on the bundle.

Bob Dolin (Jan 14 2020 at 20:22):

alternatively, we would not have the bundle. Instead, we'd just have OUT parameters 1..1 RegionStudied, 0..* Variants, and 0..* SeqPhaseReltns (which presumably means you'd then return a Parameters resource, instead of a Bundle)

Bob Dolin (Jan 14 2020 at 20:23):

sigh, but we can't do that, because I can't define multiple OUT parameters, each pointing to a different profile...

Kevin Power (Jan 14 2020 at 20:37):

sigh, but we can't do that, because I can't define multiple OUT parameters, each pointing to a different profile...

Really? Why not, seems like from reading OperationDefinition you should be able to?

Bob Dolin (Jan 14 2020 at 20:41):

@Kevin Power I don't see a way to associate each OUT parameter with a profile.

Kevin Power (Jan 14 2020 at 20:42):

OH, I thought you meant just multiple OUT parameters - sorry, I didn't catch the 'different profile' part.

Kevin Power (Jan 14 2020 at 20:43):

What about http://build.fhir.org/operationdefinition-definitions.html#OperationDefinition.parameter.targetProfile ? Is the problem that is just isn't rendering but maybe it works otherwise?

Bob Dolin (Jan 14 2020 at 20:44):

That was the main issue. I think the semantics are right, but it doesn't render. I suppose I could go that route and also include the canonical URL in parameter.documenation?

Kevin Power (Jan 14 2020 at 21:00):

I still don't know which is better (multiple OUT params or a Bundle) - maybe @Lloyd McKenzie would guide us?

Lloyd McKenzie (Jan 14 2020 at 21:35):

Multiple 'out' params allows you to be clear about what each parameter is for and easily control the cardinality of each one. You can also have a deep hierarchy and mix resources with individual data elements (booleans, codes, integers, etc.). A Bundle of resources is primarily useful when all of the results will be tied together using natural relationships within the Bundle and all meaning can be extracted from there. If the semantics are clearly expressed that way, then the Bundle is a more interoperable and intuitive way of sharing the data.

Bob Dolin (Jan 14 2020 at 22:42):

@Lloyd McKenzie If we go with multiple OUT parameters, do you know of any way to get the profile for each one to render?

Lloyd McKenzie (Jan 14 2020 at 23:15):

The outputProfile would be a profile on Parameters

Bob Dolin (Jan 15 2020 at 00:18):

Latest build (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html) includes multiple OUT parameters, and a new section on normalization. Next is to add some examples, and then I think it'll be ready for folks to start throwing stones at it...

Kevin Power (Jan 15 2020 at 16:10):

One question RE: normalization - would we go so far as to say it is 'required' for implementers of this Operation? Without it, these examples you referenced wouldn't be returned in the same query:

component:genomic-dna-chg: HGVS = NC_000019.9:g.11200236G>A
component:genomic-dna-chg: HGVS = NC_000019.10:g.11089560G>A

Bob Dolin (Jan 15 2020 at 16:13):

That's a good point - you can't really implement the operation without normalization, but we don't prescribe how to do it, but rather, just offer guidance/suggestions - is that what you're getting at?

Bob Dolin (Jan 15 2020 at 16:16):

but there's another subtlety, that I was thinking we didn't need to get in to - the notion of 'liftOver' (https://genome.sph.umich.edu/wiki/LiftOver). If my VCF was generated based on build 37, and the query comes in with a build 38 refSeq, there's nothing that says whether an implementation must also try to retrieve build37-based variants.

Kevin Power (Jan 15 2020 at 16:18):

I am not sure what the right answer is, but I think we need to discuss the ramifications more. A simple implementation of the operation (lookup by only the data given) could obviously miss things - we need to decide how comfortable we are with that.

Jamie Jones (Jan 15 2020 at 16:21):

looking up by only the data given could be done using a complex search query and likely wouldn't need an operation

Bob Dolin (Jan 15 2020 at 16:22):

a couple options come to mind: [1] just describe this caveat in the documentation (and let liftOver be up to the specific implementation); [2] add another operation that lets you retrieve metadata (available builds) so that you can then selectively query for the build(s) you want; [3] expect that a conformant operation implementation would implement liftOver.

Kevin Power (Jan 15 2020 at 16:24):

I would lean towards [1], but am wondering if [3] is the right answer. To Jamie's point, if you are just using the data you were given, do you really need to support this Operation?

Jamie Jones (Jan 15 2020 at 16:25):

the operation highlights the normalization issues and pitfalls of ignoring them. I'm of the opinion that all normalization (including liftOver) should be required to be a conformant implementation of the operation.

Bob Dolin (Jan 15 2020 at 16:26):

I'd kinda lean towards [1], given there are some 'gotchas' with liftOver - it doesn't always work, and the results can change. In our local implementation, we went with [2].

Jamie Jones (Jan 15 2020 at 16:26):

deriving variants on demand from other formats does circumvent the normalization

Jamie Jones (Jan 15 2020 at 16:27):

I like [2], to be able to ask a server what normalization operations it can perform seems very valuable

Jamie Jones (Jan 15 2020 at 16:27):

even very simple servers can respond to that with "none, thank you very much"

Bob Dolin (Jan 15 2020 at 16:29):

ah, I was thinking that [2] gave patient-specific information (e.g. for patient HG00403, we are storing build37 and build38 data), but you are suggesting that instead [2] not be patient-specific, but rather talks about the types of normalization (i.e. if liftOver is included).

Bob Dolin (Jan 15 2020 at 16:32):

What if, for now, we add another section, 'liftOver', and describe the issue, and note that implementations may vary, so you may need to query with both build37 and build38 refSeqs?

Jamie Jones (Jan 15 2020 at 16:33):

Highlighting these potential issues as much as possible seems the best approach for now

Jamie Jones (Jan 15 2020 at 16:42):

I don't know much about these specific normalization issues. Perhaps another response code could simplify the situation; "unable to normalize patient data to the query"

Jamie Jones (Jan 15 2020 at 16:43):

something along these lines would prompt the user to try different queries

Bob Dolin (Jan 15 2020 at 16:44):

I thought about that, but I think you only get to send back a single response code, so where the request is based on a build37 refSeq, and the patient has build37 and build38 data, would you not send anything back, just the new response code?

Jamie Jones (Jan 15 2020 at 16:52):

If a server could easily tell it had more data than was being returned, I'm not sure a 200 OK is the correct response. Can we allow multiple reference sequences in the IN parameter?

Bob Dolin (Jan 15 2020 at 16:54):

hmmm, I think it gets complicated pretty quickly, when the service accepts multiple regions, across different builds. Maybe that would be a future operation?

Bob Dolin (Jan 15 2020 at 16:56):

what if we say, by default, an operation need only respond with variants based on the requested build, and it is up to the requestor if they want to query twice?

Bob Dolin (Jan 15 2020 at 16:57):

and that optionally, some implementations may choose to include liftOver

Kevin Power (Jan 15 2020 at 19:08):

Another consideration - in the two variants from above:

component:genomic-dna-chg: HGVS = NC_000019.9:g.11200236G>A
component:genomic-dna-chg: HGVS = NC_000019.10:g.11089560G>A

So let's say a smart server does normalization and realizes it should return both of these. I noticed that the Region Studied only allows 0..1 on the genomics ref seq component. Would it respond with whichever one was in the request?

Kevin Power (Jan 15 2020 at 19:15):

Another question for region-studied.component:ranges-examied - is this the range given to the Operation, or what was really examined that happened to include this range?

Imagine this use case:

• Sequenced an Exon, and found a variant
• find-variants range is really the full Gene, so we return the variant
• the region-studied.component:ranges-examined should be ?

Jamie Jones (Jan 15 2020 at 19:19):

The proposal currently has the OUT region-studied match the query IN range, as it is interpreting the query as the 'study'. This is not completely compliant with our "region-studied is there to help describe the test done by the laboratory" ideology (that is not very well documented anywhere at this time).

Bob Dolin (Jan 15 2020 at 19:30):

This is also where I was considering the inclusion of an optional IN parameter 'includeUncallableSubregions' (boolean), which would identify that the intron regions weren't studied.

Kevin Power (Jan 15 2020 at 19:51):

I didn't see what ranges are expected documented, which we should do.

And this is different from uncallable, right? This is "you asked for variants in a region, but I only tested a part of that region" - I guess the outcome is the same, but I wouldn't use the word uncallable.

This is starting to make me uncomfortable using Region Studied as an OUT parameter. It sounds like we are redefining what the range-examied component means, right?

Bob Dolin (Jan 15 2020 at 20:16):

well, Grahame once told me that we really don't HAVE to reflect back what the query parameters were... Anyhow, what do you think if I make a few more edits based on some of today's discussion, and then maybe we should move the discussion to the normal Zulip genomics channel?

Kevin Power (Jan 15 2020 at 20:38):

Geesh, sorry - I didn't even realize we were in the committers stream :dizzy:

Bob Dolin (Jan 15 2020 at 21:05):

ok, page has been updated: [1] added an example; [2] included discussion of normalization and liftover. Still need to work through @Kevin Power 's comment regarding RegionStudied, @Jamie Jones's comment regarding the need for a Provenance OUT parameter, note on google doc questioning if genomic-source-class needs to be required. I think most of @Bret H's questions on the google doc are addressed by having done away with DR. We can continue the discussion on the Zulip genomics channel.

Patrick Werner (Feb 22 2020 at 18:33):

After the discussion in last weeks call about the base of this operation would be better on/Observation, i had another look on the current branch and wanted to post some thought of mine:

• as this is a query on a single subject i'd like to discuss changing the name to find-subject-variants.If we later decide to add a subject independent query we then can name it find-variants
• the OUT Parameters are currently having the data type canonical, which is used to reference conformance resources uris. These should be changed to Observation

Jamie Jones (Feb 22 2020 at 18:41):

Good catch with canonical. I also think the name should imply it is patient level and not system level

Kevin Power (Feb 22 2020 at 19:13):

Regarding the operation name, is there any guidance we can follow so that we align with other FHIR operations? For example, should we lean towards fewer and generic operations, which would imply some optional parameters? Or is the idea to have more specific operations?

Patrick Werner (Feb 23 2020 at 12:59):

Kevin Power said:

Regarding the operation name, is there any guidance we can follow so that we align with other FHIR operations? For example, should we lean towards fewer and generic operations, which would imply some optional parameters? Or is the idea to have more specific operations?

good question. I would be in favour of fewer operations. But changing subject to 0..1 wont help a endpoint which only can do a subject specific query. Then the server endpoint might implement a subject specific operation and choose its own operation name. So i think two operations, one subject related, one independent would be ok.

Patrick Werner (Feb 23 2020 at 13:00):

i corrected the out parameters to Reference, but the build fails (not sure if it was failing already before my change). Will have a closer look next week.

Kevin Power (Feb 24 2020 at 18:58):

Hi all - I am including a discussion about these things on the operation in Tuesday's agenda. Is that OK @Bob Dolin and @Patrick Werner ?

Bob Dolin (Feb 24 2020 at 19:05):

sounds great to me. Thanks @Kevin Power .

Patrick Werner (Feb 25 2020 at 07:55):

+1

Bob Dolin (Feb 26 2020 at 02:23):

The find-subject-variants operation (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-subject-variants.html) has been updated:

Bob Dolin (Feb 26 2020 at 02:24):

• updated Table of Contents to point to $find-subject-variants
• updated Operations.html to point to $find-subject-variants
• updated Operations.html to include hyperlink to http://hl7.org/fhir/operations.html
• updated $find-subject-variants to include hyperlink to http://hl7.org/fhir/parameters.html
• updated $find-subject-variants OUT parameters to be Observations, with no targetProfile

Kevin Power (Feb 27 2020 at 16:19):

Thanks @Bob Dolin ! Would you mind reviewing the Resolution Description on the JIRA and suggesting updates based on your changes? https://jira.hl7.org/browse/FHIR-25250

Bob Dolin (Feb 27 2020 at 16:34):

Thanks @Kevin Power . I'm not sure I have rights to edit the Resolution Description. Here's a suggested update:

Bob Dolin (Feb 27 2020 at 16:34):

Resolution is to merge the $find-subject-variants operation (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-subject-variants.html) into the Master branch. (Additional change proposals to the operation are still welcome, and will be managed in the Master branch).

Description of $find-subject-variants operation:

Use this operation to retrieve variants with precise endpoints from a specified genomic region for a specified patient. If the range in question has been studied, the operation returns variants overlapping the region. If the patient or the specified region has not been studied, the operation returns a 404 error.

IN Parameters:
subject [1..1]
genomicRefSeq [1..1]
range (numeric within the ref seq) [1..1]

OUT Parameters:
regionStudied [0..1]
variant [0..*]
sequencePhaseRelationships [0..*]

Details of the operation are here: http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-subject-variants.html

Kevin Power (Feb 27 2020 at 16:38):

Thanks @Bob Dolin - two wonderings:
1 - Should we mention the [base] we decided on?
2 - I had listed the following, should we leave it or remove?

Other Requirements:

• Include discussion of variant normalization, and expectations of the server
• Include discussion of variant liftover, and expectations of the server

Bob Dolin (Feb 27 2020 at 16:50):

Okido, how about this:

Bob Dolin (Feb 27 2020 at 16:50):

Resolution is to merge the $find-subject-variants operation (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-subject-variants.html) into the Master branch. (Additional change proposals to the operation are still welcome, and will be managed in the Master branch).

Description of $find-subject-variants operation:

Use this operation to retrieve variants with precise endpoints from a specified genomic region for a specified patient. If the range in question has been studied, the operation returns variants overlapping the region. If the patient or the specified region has not been studied, the operation returns a 404 error.

IN Parameters:
subject [1..1]
genomicRefSeq [1..1]
range (numeric within the ref seq) [1..1]

OUT Parameters:
regionStudied [0..1]
variant [0..*]
sequencePhaseRelationships [0..*]

Additional resolutions include:

• operation name: $find-subject-variants
• context: [base]/$find-subject-variants
• include discussion of normalization and liftover, including expectations of the server

Details of the operation are here: http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-subject-variants.html

Bob Dolin (Mar 10 2020 at 20:29):

@Kevin Power @Jamie Jones Being a bit of a github novice, I thought I'd run this by you before starting. I can go ahead and create a pull request for the fhir_operations branch. Did you also want me to do the merge?

Jamie Jones (Mar 10 2020 at 20:36):

I have some time to look into the merge

Kevin Power (Mar 10 2020 at 20:37):

Certainly do the pull request. It is probably a good habit for our group to have someone else do a review and then merge.

Bob Dolin (Mar 10 2020 at 20:40):

good news - the branch has no conflicts with the base branch, and can be automatically merged.

Bob Dolin (Mar 10 2020 at 20:40):

But I'll leave the merging to one of you, just to play it safe

Jamie Jones (Mar 10 2020 at 20:42):

We were doing work in the other branch yeah

Jamie Jones (Mar 10 2020 at 20:42):

That's gonna be the harder one (and I may just port over the diff manually)

Kevin Power (Mar 10 2020 at 20:44):

I did a quick review, merged, and deleted the branch. We can watch and see if it builds OK after the merge

Kevin Power (Mar 10 2020 at 20:46):

HL7/genomics-reporting: master rebuilt
Commit: Merge pull request #5 from HL7/fhir_operations

Fhir operations (Kevin Power) :thumbs_up:
Details: build logs | published | qa: broken links = 31, errors = 28, warn = 21, info = 30

Bob Dolin (Mar 10 2020 at 20:47):

whoo hoo!!!

Kevin Power (Mar 10 2020 at 20:47):

Nice work @Bob Dolin !! You can see the operation here now: http://build.fhir.org/ig/HL7/genomics-reporting/operations.html

Bob Dolin (Mar 10 2020 at 20:48):

very exciting. Now we can start talking about the next operation ;-)

Last updated: Apr 12 2022 at 19:14 UTC